Systems and Methods for Processing a Payment Coupon Image

ABSTRACT

Embodiments of the invention may provide systems and methods for processing a payment coupon image. In one embodiment, a method includes receiving an image representing a payment coupon from a payer, determining an identity of a biller associated with the payment coupon based at least in part on information displayed by the image, and extracting data from the image based at least in part on payment coupon metadata associated with the biller indicating a layout of the payment coupon. The method may further include performing at least one of: (a) processing a payment associated with the payment coupon to the biller based at least in part on the data extracted from the image; (b) adding the biller to a list of billers for a payer associated with the payment coupon; or (c) activating the biller as an electronic biller for the payer associated with the payment coupon.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. application Ser. No.14/145,487 filed Dec. 31, 2013, which is a continuation of U.S.application Ser. No. 12/818,964, filed Jun. 18, 2010, and now issued asU.S. Pat. No. 8,635,155, the contents of which are incorporated hereinin their entireties.

FIELD OF THE INVENTION

Aspects of the invention relate generally to monetary payments, and moreparticularly to systems and methods for processing a payment couponimage.

BACKGROUND OF THE INVENTION

Many solutions exist to provide capabilities to consumers or other billrecipients for online processing and payment of bills. In one instance,a consumer who receives a hardcopy or paper bill can proceed to pay thebill electronically using an online payment and processing system. Thesystems may be offered through the consumer's financial institution, bythe biller, or by a third party service provider. To process an onlinepayment for a hardcopy bill, there are many steps to be performed andhurdles to overcome in order to achieve successful payment, particularlyif the consumer has never paid the biller before. For example, aconsumer typically has to first set up the biller as a personal billerof the consumer, which may include selecting from a list and/or manuallyentering in biller information. In addition, the consumer then has toenter the payment particulars (e.g., a payment amount and payment date)each time a new payment is to be processed. Such manual data entryprocesses are susceptible to user error (e.g., miskeying information,etc.) and can be time consuming.

These hurdles and possible complications to process bill paymentrequests based on hardcopy bills may adversely impact the adoption ofelectronic bill payment. Consumers may ultimately conclude it is easierto write and mail a paper check with the bill's payment coupon in theprovided envelope, as has conventionally been the practice.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIG. 1 illustrates an overview of an example system for capturing andprocessing payment coupon information, according to an exampleembodiment of the invention.

FIGS. 2A-2C illustrate example sets of data flows for capturing andprocessing payment coupon information, according to example embodimentsof the invention.

FIG. 3 illustrates a flow diagram of an example method for scanning apayment coupon, according to an example embodiment of the invention.

FIGS. 4A-4B illustrate a flow diagram of an example method fordetermining and processing payment coupon information from a paymentcoupon image, according to an example embodiment of the invention.

FIG. 5 illustrates a flow chart of an example method for capturingpayment coupon information, according to an example embodiment of theinvention.

FIGS. 6A-6F illustrate example user interfaces, according to exampleembodiments of the invention.

FIGS. 7A-7B illustrate a flow diagram of an example method for taking aphotograph of a payment coupon, according to an example embodiment ofthe invention.

FIGS. 8A-8D illustrate example user interfaces, according to exampleembodiments of the invention.

FIG. 9 illustrates a flow diagram of an example method for scanningmultiple payment coupons, according to an example embodiment of theinvention.

FIGS. 10A-10B illustrate a flow diagram of an example method forprocessing multiple payment coupons, according to an example embodimentof the invention.

DETAILED DESCRIPTION

The invention will now be described more fully hereinafter withreference to the accompanying drawings, in which example embodiments ofthe invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theexample embodiments set forth herein; rather, these example embodimentsare provided so that this disclosure will be thorough and complete, andwill fully convey the scope of the invention to those of ordinary skillin the art. Like numbers refer to like elements throughout.

Embodiments of the invention may provide systems and methods forcapturing and processing payment coupon information. For example,according to one embodiment, payment coupon information, which may betypically provided as part of or otherwise accompany a hardcopy billfrom a biller, may be scanned or otherwise converted to a digital imagefrom which payment coupon information can be obtained by a paymentservice provider system. For example, upon receiving a payment couponimage, a payment service provider system may extract values for each ofthe fields on the payment coupon image. These field values may beutilized by the payment service provider to perform subsequentprocessing, such as to process the corresponding payment, to add thebiller to the payer's biller list, and/or to activate the biller as anelectronic biller. Accordingly, by allowing a payer to scan a couponimage and transmit it to a payment service provider system forprocessing, the payer's efforts and time to process a payment requestcan be minimized.

In one example embodiment, a payment service provider system may storepayment coupon layout information (also referred to herein as “paymentcoupon metadata”) for a number of payment coupon types that will allowquick detection and determination of payment coupon field values when ascanned image is received. In one embodiment, if the payment serviceprovider system, upon receiving a scanned payment coupon image,determines that no payment coupon metadata exists for the payment coupon(e.g., none stored for the biller or the type of payment coupon), thenpayment coupon layout information may be requested from the payer. Forexample, the payer may graphically and/or textually provide informationthat indicates location, size, geometry, content, values, etc.,corresponding to one or more of the payment coupon fields. Thus, uponreceiving this payment coupon layout information, the payment serviceprovider system can then process the instant payment coupon image andstore the payment coupon layout information with the payment couponmetadata to facilitate the processing of subsequent payment couponimages from the same biller and/or of the same type.

According to various embodiments, payment coupon images may be scannedpayment coupon images obtained from a payer's computer and scannerdevice or they may be payment coupon photographs taken from a camera ona payer's mobile device. Moreover, in some embodiments, a payer mayprovide to a payment service provider system multiple payment couponimages at once, to enable batch processing for all of the paymentcoupons, further simplifying the efforts required by the payer.

As used herein, the term “payer” generally refers to an individual whois enrolled or registered with a payment service requesting or otherwiseproviding payment to another entity, such as a biller, via the paymentservice. Thus, the term “biller” generally refers to an entity receivingpayment, such as may be received via an electronic payment applicationprovided by the payment service. The term “payment service provider”generally refers to an entity operable to process payment requests madeby payers and to effectuate or direct payments to billers. The paymentservice provider may include any number of systems and or processingcomponents, which may generally be referred to as a “payment serviceprovider system,” to facilitate the processing of payment requests.Payment requests can be received by a payment service provider systemdirectly from a payer, or from any other entity on behalf of a payer.Though, according to some embodiments, a service provider is not limitedto a payment service provider, and can generally refer to any entityfacilitating transactions with other entities on behalf of itscustomers.

I. System Overview

FIG. 1 illustrates an example system 100 to facilitate capturing paymentcoupon information from a payer's device, according to an exampleembodiment of the invention. Although various computing devices and/orcomputers are illustrated in FIG. 1, it is appreciated thatcorresponding entities and/or individuals are associated with each ofthe computers illustrated. According to various embodiments, there maybe: one or more payment service provider systems 105, each associatedwith one or more payment service provider computers 160 or paymentservice provider computing devices; one or more biller systems 130,which may likewise be associated with one or more computers or computingdevices; and one or more biller financial institution systems 135, whichmay likewise be associated with one or more computers or computingdevices. There may also be one or more payers 110, each being associatedwith one or more of: a computer 115, a scanner device 120, and/or amobile device 125. The payer 110 may also be associated with one or morepayer financial institution systems 140, which may likewise beassociated with one or more computers or computing devices. According tovarious embodiments, there may be any number of each entity type, andeach entity may be associated with any number of suitable computers,computing devices, and/or other devices. For simplicity, the computers,devices, and/or entities may be referenced in the singular, but it isappreciated that the same description applies to embodiments includingmultiple computers, devices, and/or entities. Similarly, for each of thecomputers described herein, it is appreciated that the computer mayinclude any number of suitable components and/or functionality.Moreover, although detailed descriptions of system components areprovided for the payment service provider system 105 and itscorresponding payment service provider computer(s) 160, it isappreciated that any of the biller systems, the biller financialinstitution systems, and the payer financial institution systems may beconfigured in any suitable manner, which may be similar to thatdescribed herein for the payment service provider system 105.

As shown in FIG. 1, one or more of a payment service provider system105, a payer's computer 115, a biller system 130, a biller financialinstitution system 135, and/or a payer financial institution system 140may be in communication with each other via one or more suitablenetworks 145, which, as described below, can include one or moreseparate or shared private and/or public networks, including theInternet or a publicly switched telephone network. In addition a payer110 may communicate with any of the aforementioned systems via a payer'smobile device 125 over one or more wireless networks 150, which mayadditionally be in communication with the network or networks 145. Forexample, as discussed below in more detail, according to variousembodiments, the payment service provider system 105 may be operable toreceive one or more scanned payment coupon images from a payer'scomputer 115 and/or a payer's mobile device 125, or in other embodimentsfrom kiosks or other standalone devices operable for communication withthe payment service provider system 105, such as may be present in aretail establishment. The payment service provider system 105 may thencommunicate with a designated biller system 130 for processing thepayment therewith, while also communicating a credit directive to acorresponding biller financial institution system 135 and/or a debitdirective to the payer's financial institution system 140. Thesecomponents will now be discussed in further detail.

The payment service provider system 105 may include any number ofpayment service provider computers 160 that facilitate the processing ofscanned payment coupon images and payment requests. A payment serviceprovider computer 160 may be any suitable processor-driven device thatfacilitates the receipt and/or processing of scanned payment couponimages and/or payment requests, such as, but not limited to, a servercomputer, a mainframe computer, one or more networked computers, adesktop computer, a personal computer, a digital assistant, a personaldigital assistant, a digital tablet, an Internet appliance, anapplication specific circuit, a microcontroller, a minicomputer, or anyother processor-based device. The execution of suitablecomputer-implemented instructions by the payment service providercomputer 160 may form a special purpose computer or other particularmachine that is operable to facilitate the receipt and processing ofscanned payment coupon images and/or payment requests transmitted bypayers. Although a single payment service provider computer 160 isdescribed herein, the operations and/or control of the payment serviceprovider computer 160 may be distributed among any number of computersand/or processing components.

In addition to having one or more processors 164, the payment serviceprovider computer 160 may include one or more memory devices 162, one ormore input/output (“I/O”) interfaces 166, and one or more networkinterfaces 168. The memory devices 162 may be any suitable memorydevices, for example, caches, read-only memory devices, random accessmemory devices, magnetic storage devices, removable storage devices,etc. Additionally, any number of logical data storage constructs may bestored as desired within the memory devices 162, such as a paymentcoupon database 170 or any other suitable databases. The memory devices162 may further store a wide variety of data, such as data files 172.Additionally, the memory devices 162 may store executable instructionsand/or various program modules utilized by the payment service providercomputer 160, for example, an operating system 174, a databasemanagement system (“DBMS”) 176, a coupon image module 180 and/or one ormore host modules 178.

The data files 172 and/or the payment coupon database 170 may includeany suitable data that facilitates the receipt and/or processing ofpayment coupon images and/or payment requests by the payment serviceprovider computer 160. For example, the data files 172 and/or otherdatabases may include data utilized when processing payment requests,such as, but not limited to, payer information, biller information,financial institution information, processing logic, business rules, andthe like. In one example, the payment coupon database 170 may includeinformation associated with various payment coupons, such as, but notlimited to, biller information, payment coupon size, dimension,approximate field locations, field types, and the like for a number ofbillers and/or coupon types. As described below, the information in thepayment coupon database 170 may be collected from payer-transmittedpayment coupon images or photographs, or may be obtained from billers orother service providers. As used herein, the terms “payment couponmetadata” and “payment coupon information” may be used interchangeablyto generally refer to any information stored regarding the layout and/orcontent of various payment coupons. It is appreciated that theillustration of a payment coupon database 170 as a separate databasefrom the data files 172 and/or any other data storage means is providedfor illustrative purposes, and that any data may be stored in anyarrangement, separate or together with other data stored by the paymentservice provider computer 160.

The operating system (“OS”) 174 may be a suitable software module thatcontrols the general operation of the payment service provider computer160. The OS 174 may also facilitate the execution of other softwaremodules by the one or more processors 164, for example, the coupon imagemodule 180 and/or the host module(s) 178. The OS 174 may be, but is notlimited to, Microsoft Windows®, Apple OSX™, Linux, Unix, or a mainframeoperating system. The host modules 178 may include any number ofsuitable host modules, such as Web servers, email servers, short messageservice (“SMS”) processing applications, multimedia message service(“MMS”) processing applications, and/or various other modules associatedwith and/or in communication with the payment service provider system105. The host modules 178 may facilitate the receipt of payment couponimages or photographs and/or a payment request from a payer 110. Thehost module 178 may additionally facilitate communications with adesignated biller system 130, biller financial institution system 135,and/or payer financial institution system 140 associated with a paymentcoupon image or photograph or a payment request.

Additionally, in certain embodiments, the host modules 178 may beconfigured to generate and/or to present a wide variety of differentinterfaces and/or graphical user interfaces, such as one or more publicand/or private interfaces that facilitate the receipt of a paymentcoupon image or photograph and/or a payment request from a payer 110 andone or more public and/or private interfaces that facilitatecommunications with a biller system 130. A public interface may be awebpage or a mobile webpage that is generally available to the public. Aprivate interface may be an interface that is restricted to registeredusers of the payment service provider system 105 and/or a partner entity(e.g., a partner financial institution) of the payment service providersystem 105. As desired, a private interface may be branded in accordancewith specifications and/or preferences of a partner entity.Additionally, as desired in certain embodiments, the host modules 178may be configured to provide a web services interface layer to anotherentity or component of the system 100.

The coupon image module 180 may be operable, configured, and/orprogrammed to receive one or more payment coupon images or photographsprovided by a payer 110 and/or to process a received payment requestassociated with a payment coupon image or photograph. Payment couponimages or photographs (which may be collectively referred to herein as“images”) may be received by the payment service provider system 105from a payer's computer device 115 over the network 145, such as theInternet, or from a payer's mobile device 125 over a wireless network150 and/or the network 145. In one embodiment, if a payer's mobiledevice 125 is used to transmit a payment coupon photograph by accessinga webpage associated with the payment service provider system 105, thepayment coupon photograph may be received in the same or similar manneras one transmitted from a payer's computer device 115 over the network145. In another embodiment, if a payer's mobile device 125 is used totransmit a payment coupon photograph to the payment service providersystem 105, the payment coupon photograph may be transmitted as a textmessage (e.g., an MMS message) over the wireless network 150 to a textmessage server operated by or otherwise associated with the paymentservice provider system 105 for receiving text messages. Accordingly,the coupon image module 180 may be configured and operable to receivepayment coupon images and associated information over a wireless networkas a text message over the wireless network 150 and/or as web (or othernetwork) messages over a network 145. In response, the coupon imagemodule 180 processes the coupon image to determine whether paymentcoupon metadata already exists for the type of payment coupon imagereceived, transacts with the payer device(s) to obtain additionalinformation if necessary, stores and/or updates existing payment couponmetadata or other information (e.g., in the payment coupon database 170,etc.) and, optionally, processes one or more payment requests with oneor more biller systems 130, biller financial institution systems 135,and/or payer financial institution systems 140 associated with thepayment coupon image received. Additional details of the operations ofthe coupon image module 180 and/or additional payment service providersystem 105 operating logic and functionality are provided below withreference to FIGS. 2A-10B.

With continued reference to the payment service provider computer 160,the one or more I/O interfaces 166 may facilitate communication betweenthe payment service provider computer 160 and one or more input/outputdevices; for example, one or more user interface devices, such as adisplay, keypad, mouse, pointing device, control panel, touch screendisplay, remote control, microphone, speaker, etc., that facilitate userinteraction with the payment service provider computer 160. The one ormore network interfaces 168 may facilitate connection of the paymentservice provider computer 160 to one or more suitable networks, forexample, the network(s) 145 and/or the wireless network 150 illustratedin FIG. 1, or local area network(s) within the payment service providersystem 105. In this regard, the payment service provider computer 160may receive and/or communicate information to other components of thesystem 100, such as the payer's computer 115, the payer's mobile device125, the biller system 130, the biller financial institution system 135,and/or the payer financial institution 140. As desired, any number ofwebpages, interface screens, and/or other presentations (e.g., graphicaluser interfaces, etc.) may be provided or presented to a payer 110, abiller system 130, a biller financial institution system 135, and/or apayer financial institution system 140 via the network interfaces 168.

With continued reference to FIG. 1, a payer 110 who presents one or morepayment coupon images for processing by the payment service providersystem 105 may be associated with any number of payer devices, such as acomputer 115, a scanner device 120, and/or a mobile device 125. Any ofthe aforementioned payer devices may generally facilitate the generationand communication of payment coupon images, as well as additionalcorresponding communications, with the payment service provider system105. A computer 115 may include, but is not limited to, a personalcomputer, a laptop computer, or any other suitable processor-baseddevice. A scanner device 120 may include any suitable image scanneroperable to convert any image into digital data, such as, but notlimited to, a flatbed scanner, a feed scanner, a combinationprinter/scanner, a wand scanner, a hand scanner, a film scanner, etc. Amobile device 125 may include any device operable for wirelesscommunication means (e.g., cellular, satellite, Wi-Fi Internetcommunications, WiMAX network communications, and the like), such as,but not limited to, a mobile phone, a pager device, a smart phone, anyother mobile communications device, a personal audio player, a personaldevice assistant, a laptop computer, a portable computer, or any othersuitable portable device operable for wireless communications. Eachmobile device 125 may include a camera or other means for capturing adigital image of a payment coupon.

As an example, according to one embodiment, the computer 115 may beoperable to interface with the scanner device 120 to generate paymentcoupon images utilizing the scanner device 120 and to transmit paymentcoupon images to the payment service provider system 105 over a network145 (e.g., the Internet, etc.). A payer 110 may further utilize thecomputer 115 to receive and respond to messaging from the paymentservice provider system 105 over the network 145, such as, but notlimited to, to provide field indicators, field types, and/or additionalinformation regarding a payment coupon image and/or to provide paymentrequest information. According to another embodiment, a payer 110 mayinstead, or additionally, utilize a mobile device 125 (e.g., a mobilephone having a camera) to capture a digital image of a payment coupon,and to identify field indicators, field types, and/or other additionalinformation regarding a payment coupon image. A mobile device 125 maythus be operable to transmit and to receive data over a wireless network150, and may further be operable to access one or more webpages operatedby, or otherwise associated with, the payment service provider system105 over the Internet. For example, a mobile device 125 may beconfigured for Internet (or other network 145) access using the wirelessnetwork 150, for text messaging (e.g., SMS and/or MMS messages, etc.)over the wireless network 150, for email communications over thewireless network 150 and/or the Internet (or other network 145), and thelike.

Accordingly, each of the various types of payer devices may include awide variety of suitable components as desired in various embodiments ofthe invention. For example, a payer's computer 115 or mobile device 125may be a suitable processor-driven device that includes a client module,such as an Internet browser or other dedicated program, that facilitatescommunication with the payment service provider system 105, for example,the host module 178 (e.g., a web server, a text message server, an emailserver, etc.). In certain embodiments, more than one payer device may beutilized by a payer 110. For example, a first payer device may beutilized by the payer 110 to scan and transmit a payment coupon image tothe payment service provider system, and a second payer device may beutilized by the payer 110 to transmit a payment request to the paymentservice provider system 105.

Although not described or illustrated in detail, each biller system 130,biller financial institution system 135, and payer financial institutionsystem 140 may be configured in the same or similar manner as describedfor the payment service provider system 105. For example, each billersystem 130, biller financial institution system 135, and payer financialinstitution system 140 may include one or more processor-based computersoperable to store and execute computer-executable instructions, eachhaving one or more processors, memories, I/O interfaces, networkinterfaces, operating systems, data files, databases or other datastorage means, DBMS, host modules and other operating logic to performsome or all of the same or similar functions as are described hereinwith reference to the payment service provider system 105.

The network 145 may include any number of telecommunication and/or datanetworks, whether public, private, or a combination thereof, includingbut not limited to, the Internet, a local area network, a wide areanetwork, an intranet, intermediate handheld data transfer devices,public switched telephone networks, and/or any combination thereof andmay be wired and/or wireless. The wireless network 150 may be anywireless network operable for wireless communications operating underany cellular or other wireless network protocol (e.g., GSM, CDMA, TDMA,etc.). In addition, the wireless network 150 may provide wirelessconnectivity with the network 145 (e.g., the Internet). The network 145and the wireless network 150 may also allow for real-time, off-line,and/or batch transactions to be transmitted thereover. Due to networkconnectivity, various methodologies described herein may be practiced inthe context of distributed computing environments. Although the system100 is shown for simplicity as including one intervening network 145 andone wireless network 150, it is to be understood that any other networkconfiguration is possible, which may optionally include a plurality ofnetworks, each with devices such as gateways and routers, for providingconnectivity between or among networks.

Those of ordinary skill in the art will appreciate that the system 100shown in and described with respect to FIG. 1 is provided by way ofexample only. Numerous other operating environments, systemarchitectures, and device configurations are possible. Other systemembodiments can include fewer or greater numbers of components and mayincorporate some or all of the functionality described with respect tothe system components shown in FIG. 1. Accordingly, embodiments of theinvention should not be construed as being limited to any particularoperating environment, system architecture, or device configuration.

II. Operational Overview

FIGS. 2A-2C illustrate example data flows for processing payment couponimages received from a payer, according to example embodiments of theinvention. FIG. 2A illustrates an example set of data flows 200 in whicha payer accesses a web-based payment coupon imaging application fortransmitting a payment coupon image to a payment service provider system105, according to one embodiment. For example, a payer may utilize apayer device 115, such as a computer, to access the web-based paymentcoupon imaging application over a network 145, such as the Internet. Asused herein, the terms “web-based application” and “thin clientapplication” may be used interchangeably to generally refer toapplications accessed over a network for which much, if not all, of theassociated processing is performed remote from the payer (or otherentity) accessing and/or otherwise utilizing the application, such asvia a web browser. It is appreciated, however, that, in someembodiments, even a “web-based” or “thin client” application may includesome functionality that can be executed locally.

Accordingly, with continued reference to the set of data flows 200 ofFIG. 2A, web-based payment application webpages 202 may be transmittedfrom the payment service provider system 105 to the computer 115. In oneembodiment, one or more additional applets 204 or other applications maybe transmitted to the computer 115 and stored thereon for localexecution, which may be utilized to issue control commands and otherwiseinteract with a scanner device 120 when scanning payment coupon images.It is appreciated, however, that in other embodiments, additionalapplets 204 or other applications may not be needed, and scanner device120 control may be provided entirely within/from the webpage or webpages202 accessed. Upon scanning, one or more payment coupon images 206 aretransmitted from the computer 115 to the payment service provider system105 for processing. When processing each payment coupon image 206, thepayment service provider system 105 may in some instances requestadditional information and/or request confirmation or modification byone or more subsequent webpages 208 transmitted to the payer's computer115, and the payer may respond 210 thereto. For example, in oneembodiment, for a payment coupon associated with a biller for which thepayment service provider system 105 does not already have any paymentcoupon metadata stored, the payer may provide payment coupon layoutinformation in the response 210. The payment service provider system 105may therefore store and/or update payment coupon metadata or otherinformation, which may be used to for subsequent payment requestprocessing for the instant transaction and/or for later transactions fora same or similar payment coupon image. It is appreciated thatadditional communications may be exchanged between the payment serviceprovider system 105 and the payer's computer 115 (and/or other payerdevice), and that the aforementioned data flow is provided forillustrative purposes.

FIG. 2B illustrates an example set of data flows 225 in which a payerutilizes, at least in part, a locally stored and executed payment couponimaging application for scanning and transmitting a payment coupon imageto a payment service provider system 105, according to one embodiment.Applications which are stored and/or executed locally on the payer'scomputer 115 (or other payer device) may be generally referred to hereinas “fat client applications” or “local applications.” It is appreciatedthat, in some embodiments, a combination of local and web-based paymentcoupon imaging applications may be utilized to perform variousoperations described herein. In the embodiment of FIG. 2B, a payer maysubmit request 222 for a local payment coupon imaging application tofacilitate payment coupon image scanning and transmitting. The localpayment coupon imaging application 224 may be transmitted from thepayment service provider system 105 (or any other system from which thelocal application may be available). After downloading and installingthe local payment coupon imaging application 224, it may be executed tocontrol a scanner device 120 to generate a digital image of one or morepayment coupons and to transmit one or more payment coupon images 226 tothe payment service provider system 105 for processing. To transmit thepayment coupon image or images 226, the local payment coupon imagingapplication may establish a communication link between the computer 115and the payment service provider system 105 over the network, such as byaccessing one or more webpages over the Internet or by initializing aprivate network session therebetween. Like that described with referenceto the set of data flows 200 illustrated by FIG. 2A, in response toreceiving the payment coupon image or images 226, the payment serviceprovider system 105 may then request additional information and/orrequest confirmation or modification by one or more subsequent webpages228 transmitted to the payer's computer 115, and the payer may respond230 thereto, after which the payment service provider system 105 maytherefore store and/or update payment coupon metadata or otherinformation.

In another embodiment, the set of data flows 225 may similarly representcommunications between a payer's mobile device 125 and the paymentservice provider system 105 in the same or similar manner as describedfor a computer 115. For example, a local payment coupon imagingapplication 224 may be downloaded and installed on the mobile device125, which may be used to control or otherwise interact with the cameraof the mobile device 125 for generating a digital payment couponphotograph. The payment coupon image 226 may likewise be transmittedover the Internet (or another network 145) or may be transmitted as atext message (e.g., a MMS message) over a wireless network 150 to thepayment service provider system 105. The payment service provider system105 may likewise request additional information and/or requestconfirmation or modification by one or more webpages 228 (or one or moretext messages) sent to the mobile device 125, to which the payer mayrespond 230 accordingly.

FIG. 2C illustrates an example set of data flows 250 for receiving andprocessing a payment request associated with a payment coupon image,according to one embodiment. According to this embodiment, the paymentservice provider system 105 receives a payment request 252 from a payerdevice, such as a computer 115 or a mobile device 125. According to oneembodiment, the payment request 252 may be embodied as, or otherwiseassociated with, a payment coupon image transmitted by the payer to thepayment service provider system 105, such as is described with referenceto FIGS. 2A-2B. For example, the payment service provider system 105 maytreat a received payment coupon image as a payment request 252. Inanother embodiment, a payment request 252 may be transmitted at sometime after transmitting the corresponding payment coupon image, such asif the payment coupon imaging application subsequently inquires whethera payment request is to be processed in association with the receivedpayment coupon image. In response to receiving a payment request 252,the payment service provider system 105 may process the informationassociated therewith. Example processing may include, but is not limitedto, identifying the payer and corresponding account information and/orother identifiers, the payment amount, the payment date, the biller towhich the payment is to be issued, the biller's financial institutionsystem and corresponding account information, the payer's financialinstitution system information, and the like. For example, to completethe payment as requested by the payment request 252, the payment serviceprovider system 105 may transmit notification of or otherwise post 254the corresponding payment to the biller system 130, direct a credit 256by an amount associated with the payment request 252 to thecorresponding financial account of the biller at a biller financialinstitution system 135, and direct a debit 258 to the payer's account atthe payer financial institution system 140 by the same amount (orgreater if there are fees associated therewith) associated with thepayment request 252. In this regard, a payment from the payer to thebiller may be completed. A wide variety of suitable communicationnetworks 145 may be utilized to facilitate communication of the creditdirective 256 and/or the debit directive 258 as desired in variousembodiments of the invention. For example, an Automated Clearing House(“ACH”) network, banking network, the Internet, and/or any othersuitable private or public network may be utilized. It is appreciatedthat the aforementioned data flow is provided for illustrative purposes,and that additional communications may be exchanged between the paymentservice provider system 105, the payer's computer 115 (and/or otherpayer device), the biller system 130, the biller financial institutionsystem 135, and/or the payer financial institution system 140, such asconfirmation communications, and the like. Moreover, in someembodiments, a payment request may not result from a payer transmittingone or more payment coupon images, such as if the payment coupon imagesare only used for adding a biller to the payer's list of approvedbillers or as an electronic biller for the payer.

It is appreciated that the above-described sets of data flows 200, 225,250 are provided for illustrative purposes, are not intended to belimiting, and that other operations may be performed to capture andtransmit one or more payment coupon images to a payment service providersystem and to perform subsequent processing responsive thereto.Additional variations will be apparent in light of the following flowdiagrams describing example operations in more detail.

FIG. 3 represents a flow diagram of an example method 300 for capturinga payment coupon image by a payer and transmitting the payment couponimage to a payment service provider for processing, according to oneembodiment. In example embodiments, certain operations of the method 300may be performed by one or more payment service provider computersassociated with a payment service provider system, such as the paymentservice provider computers 160 associated with the payment serviceprovider system 105 described with reference to FIG. 1, while otheroperations may be performed by a payer's computer and scanner device incommunication therewith, such as a computer 115 and scanner device 120described with reference to FIG. 1. However, in other embodiments,certain operations of the method 300 may be performed by one or moreother components, such as by one or more suitable financial institutionsystems instead of, or in addition to, the operations performed by thepayment service provider system.

According to various example embodiments, a payment coupon imagingapplication may be accessed over a network 145, such as the Internet, bya payer 110 utilizing a web browser of a computer 115. In oneembodiment, the payment coupon imaging application may be a thin clientapplication operated by or on behalf of a payment service provider. Inanother embodiment, the payment coupon imaging application may be a fatclient application installed and executed locally by the payer'scomputer 115, which may be downloaded over the network 145 from thepayment service provider system 105 (or other system) or installed fromlocal media (e.g., removable disc, removable storage drive, etc.). Evenwith a fat client implementation, network 145 access will be providedbetween the payer's computer 115 and the payment service provider system105 to transmit scanned payment coupon images and to exchange subsequentcommunications while processing the payment coupon images. In yet otherembodiments, the payment coupon imaging application may be provided as acombination of thin and fat client applications, accessed over thenetwork 145 and executed utilizing a web browser, but having somefunctionality provided by locally executed applications, such as webapplets operable for controlling or otherwise interacting with a scannerdevice 120 in communication with the computer 115.

For example, in one embodiment, a local application component may bedownloaded over the network 145 to the computer 115 each time thepayment coupon imaging application is invoked and one or more webpagesare delivered. The local application component may be provided bysoftware code embedded in one or more webpages (e.g., Javascript code,ActiveX, etc.) which may be downloaded as an accompanying applicationapplet when one or more webpages are delivered, although it need not bepersisted locally at the computer 115. In another embodiment, a localapplication component, such as, but not limited to, an ActiveX control,a Javascript applet, or other suitable programming embedded in orassociated with one or more webpages of the payment coupon imagingapplication, may be similarly downloaded to the computer 115 once thefirst time the payment coupon imaging application is invoked and one ormore webpages are delivered. However, in this embodiment, the localapplication component may be persisted locally at the computer 115 sothat it only needs to be downloaded or otherwise updated again if theversion is no longer up-to-date, which may be accomplished by anysuitable mean. In yet another embodiment, one or more webpages of thepayment coupon imaging application may invoke one or more operatingsystem functions from within the webpage that are operable to provideaccess to and interaction with the scanner device 120 and other localfunctionality (e.g., access to memory, etc.). It is appreciated that theaforementioned example implementations are provided for illustrativepurposes only, and that any other suitable implementation for providingpayment coupon imaging scanning and transmitting functionality between apayer's computer 115 and a payment service provider system 105 may beprovided, according to various embodiments. Moreover, while thefollowing method 300 is described as occurring between the payer (on theride side of the figure) and a payment service provider (on the leftside of the figure), it is appreciated that the same or similar methods(and other methods described herein) can be performed by and betweenother entities, such as between the payer and a biller, between thepayer and a biller financial institution, between the payer and a payerfinancial institution, and the like.

With continued reference to FIG. 3, the method 300 may begin at block305. At block 305, an option to scan a payment coupon image may bepresented to the payer 110. For example, when accessing an online billpayment application, one or more webpages may present the option. In oneembodiment, a separate webpage providing payment coupon scanningcapabilities may be presented, which may be accessible from a separatetab or other separate module accessible within the online bill paymentapplication. In another embodiment, a payment coupon scanning option maybe presented along with other payment processing options, such as, butnot limited to, an option that is selectable (e.g., hyperlink, radiobutton, etc.) after selecting to make a payment. FIG. 6A illustrates anexample user interface 605 presenting an option to scan a payment couponwith each biller for which the option may be available (the “usescan-and-pay” hyperlink), according to one embodiment. The userinterface 605 may be the first webpage from which a payment couponscanning option is available, or it may be a subsequent webpagepresented after a payer 110 initially selects the option from a firstwebpage. In one embodiment, the user interface 605 may not be a separatewebpage, but instead may be a separate window that executes from withinanother webpage. It is appreciated that any number of user interfaceoptions for presenting payment coupon scanning functionality to a payer110 may be provided, and that the aforementioned examples andillustrations are provided for illustrative purposes and are notintended to be limiting.

Following block 305 is block 310, in which the payer 110 may select theoption to scan a payment coupon, which is received by the paymentservice provider system 105 at block 315. After receiving the selectedoption to scan a payment coupon, operations continue to block 320, inwhich control of the scanner device 120 in communication with thepayer's computer 115 is invoked, according to one embodiment. Asdescribed above, control of the scanner device 120 may be accomplishedby any number of methods, including, but not limited to, an applet orother local application component downloaded for local execution on thecomputer 115 or a webpage-based operation executed from within the webbrowser/webpage. As part of invoking control of the scanner device 120,an application may include logic to perform one or more of the followingscanner device identification functions: identify all available scannerdevices, present the user with an option to select a scanner device,assume a default scanner device, identify a current default scannerdevice, and/or activate the scanner device. After identifying thescanner device 120 to be utilized, the application may continue toaccess and issue control commands to the scanner via a locally installedscanner driver. In one embodiment in which the previously indicateddefault scanner device is utilized or a default scanner device isassumed, control of the scanner functionality may not be needed untilblocks 330-340 are performed, where actual scanning and transmitting areperformed. Moreover, in another embodiment, the payment coupon imagingapplication may not control, activate, or otherwise interact with thescanner device, such as if the activation and control are manuallyprovided by the payer (e.g., at block 330), including subsequentlyinputting to the payment coupon imaging application a memory locationfor one or more files containing a scanned payment coupon image.

Following block 320 is block 325, in which instructions on how toperform payment coupon scanning may be presented to the payer 110.According to various embodiments, the instructions may be presented bytransmitting a separate webpage to the computer 115 or by presenting anapplet or other window from the same webpage presently being viewed. Anynumber of payment coupon scanning instructions may be presented to thepayer 110, depending upon the particular implementation.

For example, according to some embodiments, the payment coupon scanninginstructions may request that the payer 110 physically separate thepayment coupon from other bill information present on the papercontaining the payment coupon and/or that the payer 110 orient thepayment coupon within the scanner device 120 in a particular manner. Forexample, payment coupon scanning instructions may request that a certainedge (e.g., the top, etc.) be aligned with a certain area of the scannerdevice 120 (e.g., along the top edge of a scanner screen, along the leftside of a scanner feed tray, etc.) to facilitate determining imageorientation and subsequent processing by the payment service providersystem 105. In another example, such as if the scanner device 120 is ahand or wand scanner, the instructions may indicate a direction ofscanning relative to a particular orientation of the payment couponand/or an edge from which scanning is to begin. It is appreciated thatother payment coupon orientation instructions may be provided asdesired. Moreover, in some embodiments, the payment coupon scanninginstructions may indicate that the coupon is to be separated from thepaper on which it is displayed but may not provide any particularpayment coupon orientation instructions.

In other embodiments, the payment coupon scanning instructions maycontain instructions permitting the payer 110 to scan the entire page onwhich the payment coupon is displayed. In this example embodiment,additional orientation instructions may not be needed, because thepayment coupon would typically be embodied in a standard page size forwhich orientation is conventionally understood (e.g., 8.5 inches by 11inches, etc.). Although, in some embodiments, even if scanning astandard page size, additional orientation instructions, such as thosepresented when separating the payment coupon from the rest of the page,may also be presented.

In an embodiment in which an entire page is scanned and no orientationinstructions are presented, the payment service provider system 105,such as the coupon image module 180, may perform some additionalprocessing of the received payment coupon image to identify and isolatethe payment coupon portion. Various processing operations may beperformed based on certain assumptions of typical payment coupon layoutsand/or data identified using optical character recognition (“OCR”)techniques. For example, in one embodiment, processing operations mayassume that a payment coupon is always located at either the top or thebottom of a page along its shortest dimension (e.g., along the 8.5 inchdimension for 8.5 inch by 11 inch pages, etc.). Thus, OCR processing maybe performed to identify one or more separator tokens or otherindicators displayed on the scanned image (e.g., a separator line ofdashes, a scissors symbol, a text string such as “detach here,” etc.) toisolate the payment coupon portion from the remainder of the page. Inother embodiments, other combinations of identified information (e.g.,using OCR) and assumptions may be used, such as, but not limited to,identifying what appears to be a biller name, a payer name, an accountnumber, a bar code, etc., and determining the orientation andapproximate size of the payment coupon image based on assumptions ofknown or standard coupon layouts (e.g., where billers are traditionallyidentified, where payers are traditionally identified, barcodelocations, etc.). In some situations, there may not be any means toidentify and isolate the payment coupon from the rest of the page basedon the received payment coupon image. In these situations, the paymentservice provider system 105 may respond to the payer 110 (duringsubsequent processing as described with reference to FIG. 5) with arequest for an explicit identification of the payment coupon layout,with a rejection indicating the scanned image cannot be utilized forprocessing, with any and/or all information obtained from the paymentcoupon image (e.g., from OCR processing) for identification as to whateach piece of information represents, and the like.

According to one embodiment, payment coupon scanning instructionspresented to the payer 110 at block 325 may be presented textually(e.g., step-by-step instructions, etc.) or graphically. Graphicallypresented payment coupon scanning instructions may include arepresentation of a scanned coupon and/or its placement within a scannerdevice 120.

According to one embodiment, if the payment coupon imaging applicationis configured to allow for more than one method for scanning a paymentcoupon (e.g., allow for separated payment coupons and for entire pagescans, etc.), then the instructions presented may allow the payer 110 toselect which scanning method is to be utilized, and will thus tailor anysubsequent instructions presented to the payer 110 as well as subsequentimage processing performed by the payment service provider system 105.In other embodiments, the local or server processing may determine whichscanning option was performed based on the dimension and/or shape of thescanned payment coupon image. For example, if the received paymentcoupon image has a shape or dimension other than standard paper sizes,it may be assumed that the coupon was separated from the page on whichit was originally presented before being scanned, thus indicating thatthe entire received image likely represents the payment coupon.Otherwise, if the scanned image received is the same or similar to astandard paper size, then it may be assumed that the payment coupon wasnot first separated from the page on which it was presented, and thatadditional processing may be required to identify and isolate theportion representing the payment coupon.

Following block 325 are blocks 330-335, in which the payer 110 (or thepayment coupon imaging application) may activate the scanner device 120,at block 330, and scans a payment coupon, at block 335, according to thepayment coupon scanning instructions presented. In one embodiment, uponscanning, a scanned payment coupon image may be stored locally withinthe memory of the computer 115 or the scanner device 120, such as forperforming subsequent processing prior to transmitting the paymentcoupon image to the payment service provider system 105. FIG. 6Billustrates an example user interface 610 showing a scanned paymentcoupon image displayed to a payer 110 prior to transmission to thepayment service provider system 105. In response to viewing the scannedpayment coupon image, the payer 110 may then instruct transmission ofthe payment coupon image to the payment service provider system 105 atblock 340. It is appreciated, however, that in some embodiments, apreview screen, such as the example user interface 610 illustrated inFIG. 6B, may not be presented, and the payment coupon imagingapplication may cause the scanned payment coupon image to be transmittedimmediately in response to the payer's 110 instructions.

Upon receiving the scanned payment coupon image at block 345, thepayment service provider system 105 may then proceed to process theimage, such as is described with reference to FIGS. 4A-4B, for example.After receiving the payment coupon image, the method 300 may end, havingenabled a payer 110 to utilize a computer 115 and a scanner device 120to capture payment coupon information from a bill, which may be used tocapture biller information, add the biller to the payer's list ofbillers, and/or to process a payment for the scanned payment coupon.

While the method 300 described with reference to FIG. 3 relates toscanning a payment coupon utilizing a computer 115 and a scanner device120, FIGS. 7A-7B illustrate an example method for capturing a digitalphotograph of a payment coupon utilizing a mobile device 125, asdescribed in detail below. In addition, FIG. 9 illustrates an examplemethod for scanning multiple payment coupons utilizing a computer 115and a scanner device 120 in a manner similar to the method 300, asdescribed in detail below.

FIGS. 4A-4B represent a flow diagram of an example method 400 forprocessing a payment coupon image transmitted by a payer, according toone embodiment. In example embodiments, certain operations of the method400 may be performed by one or more payment service provider computersassociated with a payment service provider system, such as the paymentservice provider computers 160 associated with the payment serviceprovider system 105 described with reference to FIG. 1. Exampleprocessing may be performed by one or more software application modulesof the payment service provider system, such as the coupon image module180 described with reference to FIG. 1, and may perform operations suchas, but not limited to, capturing payment coupon metadata or otherinformation, adding a biller to a payer's biller list, activating abiller as an electronic biller, and/or processing a payment requestcorresponding to the received payment coupon image. However, in otherembodiments, certain operations of the method 400 may be performed byone or more other components, such as by one or more suitable financialinstitution systems and/or by a payer's device, such as by a mobiledevice 125 performing local processing, instead of, or in addition to,the operations performed by the payment service provider system.

The method 400 may begin at block 405. At block 405, the payment serviceprovider system 105 may receive a scanned payment coupon image from apayer device, such as is described with reference to FIG. 3. Asdiscussed, the payment coupon image may represent only the paymentcoupon, such as if the payer 110 separated the payment coupon from thepage on which it is displayed, or it may represent an entire pagecontaining a payment coupon and other immaterial information. Asdiscussed with reference to FIG. 3, additional processing may optionallybe performed to first identify and isolate the payment coupon from animmaterial portion of the image if it is determined that the imagereceived represents more than the payment coupon (e.g., if the paymentcoupon was not separated from the rest of the page). Details of exampleoperations to identify and isolate the payment coupon are described inmore detail with reference to block 320 of FIG. 3.

Following block 405 is block 410, in which the payment service providersystem 105 may locate a biller name or other biller identifier from theimage received, such as via OCR processing performed on the image. Oneor more OCR modules can be utilized to perform OCR processing incombination with processing logic based on known layouts of paymentcoupons. For example, known locations or approximate locations of billerinformation may be included in the processing logic to more effectivelydirect OCR processing to the likely location within the image to containbiller information. For example, payment coupons are typically one oftwo types. In a first type, payment coupons contain the biller name andaddress (and/or other biller information) at a location that is intendedto be visible through a transparent envelope window. For payment couponsof the first type, the location of the biller name and address (and/orother biller information) can be relatively predictable and definedthrough various manners, such as at a particular distance from one ormore edges of the payment coupon, or at or near approximate x and ycoordinates, etc. Payment coupons of a second type are intended forplacement in an opaque envelope with the biller name and addresspreprinted or otherwise contained on the envelope. In these cases, thelocation of the biller name and address (and/or other billerinformation) is less predictable. However, in one embodiment, ananalysis of a set of known payment coupons can be performed to identifylikely locations, notwithstanding the payment coupon type.

For example, in one embodiment, biller information can be located byfirst establishing a predefined rectangle (or other geometry) havingdimensions that will encompass a majority of biller information areas onpayment coupons, which may be defined based on experience and/or ananalysis of known payment coupons. OCR processing can then be performedon the payment coupon image at a first location within the image definedby the rectangle (or other geometry). If no identifiable charactersand/or if “noise” are identified by the OCR processing, it may bedetermined that this first location does not contain the billerinformation and subsequent locations (which may optionally beoverlapping) are similarly processed. The first location for therectangle (or other geometry) area may be decided based on thelikelihood of biller information location on payment coupons, such as totry the area with the greatest likelihood first. In another embodiment,the first location for the rectangle and/or the rectangle dimensions maybe based at least in part on known billers for the payer 110 (or othertransaction trends) that may suggest a certain location for billerinformation. It is appreciated that any other analytic technique may beused, based on known information about billers, payers, and/or paymentcoupon layouts, to define the dimension and shape of the rectangle (orother geometry) area and the location for performing OCR processing. If,however, the first area (or any other subsequent area) processed usingOCR does appear to include biller information, additional verificationprocessing may be performed. For example, the OCR processing results maybe analyzed to identify text values that would indicate confirmationthat the text string is a biller name (e.g., strings including“Company,” “Inc.,” etc.), or that the results identify text values thatindicate the information is not a biller name (or other identifier),such as, but not limited to, text values indicating an address (e.g.,strings including road name components like “Rd.,” “St.,” PO boxdesignations, states, zip codes, etc.) or payment information (e.g.,strings with a significant number to character ratio, “$,” etc.). If theresults do not appear to indicate a biller name, then OCR processing maybe performed on a different location. Otherwise, it may be assumed thatthe biller name is captured if the OCR processing does indicate at leastsome text string.

In one embodiment, if no biller information is discernable from thepayment coupon image, the payment service provider system 105 maytransmit an indication to the payer 110 (e.g., as a webpage or otherpresentation) that the biller information was not identified and requestthat the payer 110 enter the biller information. However, in otherembodiments, the operations of requesting biller information may beperformed in the same or similar manner as the operations requesting thepayer 110 to identify and capture additional payment coupon information,such as at block 420 and as described in more detail with reference toFIG. 5.

Following block 410 is decision block 415, in which the payment serviceprovider system 105 may compare the biller information obtained from thepayment coupon image via the OCR processing at block 410 to storedpayment coupon metadata, such as may be stored in the payment coupondatabase 170 described with reference to FIG. 1. The payment coupondatabase 170 may contain payment coupon metadata and/or other paymentcoupon information to indicate the payment coupon layout and tofacilitate obtaining elements from biller payment coupon images. Thepayment coupon metadata may indicate, based on a biller and/or a paymentcoupon type, a general layout of different payment coupons, which mayinclude, but is not limited to, payment coupon dimensions, paymentcoupon shape, relative location of payment coupon data (e.g., billerinformation, payer information, account information, billed amountinformation, date due information, etc.), field formats, field valuelimitations or other rules, etc. In addition, the payment coupondatabase 170 may further include information regarding types of billers(e.g., managed payees, unmanaged payees, electronic billers, etc.)and/or information regarding payers (e.g., payer preferences, accountlimitations, etc.), as well as an association between the biller and/orpayer entries in the payment coupon database 170 and other databases orstored information maintained by the payment service provider system105, such as, but not limited to, a managed payee database, a payerdatabase, a financial institution database, and the like. It isappreciated that the payment coupon database 170 (and/or any otherstored information) may include any suitable information that may beutilized to facilitate processing received payment coupon images, aswell as processing add biller requests, activate electronic billerrequests, payment requests, and the like, and is not to be limited bythe aforementioned illustrative examples.

Accordingly, by determining whether payment coupon metadata alreadyexists for the biller identified, it may be determined whether thelayout of the payment coupon is known or whether layout information isto be gathered from the payer 110. A biller match may be determinedaccording to any number of methods, including, but not limited to, anexact match of the biller name (or other identifier) obtained throughOCR processing to an authoritative biller name stored, an exact match ofthe biller name obtained through OCR processing to one of possibly anumber of biller name aliases stored, or a match of a variant of thebiller name to either an authoritative name or an alias stored. Forexample, variants or aliases may be formed by expanding or contractingname elements, or specifying commonly used or known alternative forms.

If at decision block 415 it may be determined that the biller nameobtained from the payment coupon image is not already associated withpayment coupon metadata stored in the payment coupon database 170, thenoperations continue at block 420 to capture payment coupon informationfrom the payer 110, which is described in more detail with reference toFIG. 5. For example, the image of the payment coupon may be re-presentedto the payer 110 via the payment coupon imaging application, whichallows the payer 110 to provide one or more field indicators that mayindicate location, dimension, content, value, etc., of one or morepayment coupon fields. Payment coupon fields for which field indicatorsare captured may include, but are not limited to, biller address, payeraccount number, payment amount, payment date, due date, biller phonenumber, and the like. After payment coupon information is provided bythe payer 110 at block 420, operations continue at block 430 describedbelow.

However, if at decision block 415 it is determined that payment couponmetadata does exist for the biller identified on the payment coupon,then block 425 follows. At block 425, the payment service providersystem 105 may proceed to obtain additional payment information from thepayment coupon image utilizing OCR processing and the known paymentcoupon layout provided by the payment coupon metadata for paymentcoupons by this biller. For example, OCR processing may be used toidentify certain fields and field values needed to perform subsequentprocessing. Subsequent processing may include, but is not limited to,adding the biller to the payer's biller list of approved billers,activating the biller as an electronic biller, and/or processing apayment associated with the received payment coupon. Fields that may beused during subsequent processing may include, but are not limited to,biller address, payer account number, payment due date, bill date,payment amount due, and the like.

For example, in one embodiment, biller address information may bedetermined by OCR processing performed on the payment coupon image basedon the biller address location and/or field size indicated by thepayment coupon metadata for the biller. However, in another example,biller address information may already be known, such as if it isalready stored by the payment service provider system 105 (e.g., in thepayment coupon database 170 or other memory) or if the biller is amanaged payee for which address information is not required. Thus, inthese instances, the biller address information may be captured andstored (e.g., adding the biller address to a list of known billeraddresses, etc.), or it may be ignored, choosing to rely on thepreviously stored biller address information.

In another example, payer account information contained in analphanumeric string may be determined from the payment coupon image byOCR processing. However, in other embodiments, a payment coupon maydisplay account information in a barcode, which may be analyzedaccording to a known barcode standard which the payment service providersystem 105 is operable to decipher.

In yet another example embodiment, prior to obtaining payment couponinformation from the image, the payment service provider system 105 mayfirst determine whether more than one type of payment coupon exists forthe identified biller. If the payment coupon database does includemultiple payment coupon types for the identified biller, additionalprocessing of the payment coupon image may be performed to determinewhich of the known payment coupon types the scanned image represents.For example, each payment coupon type may have a different shape and/ordimension, or may have a different biller or payer information location.Thus, OCR processing can be performed on the received payment couponimage to determine, for example, an approximate shape and/or dimensionof the payment coupon, or an approximate location of the biller or payerinformation, which may allow proper identification of the type ofpayment coupon the scanned image represents. Knowing proper layout will,in turn, permit more accurate OCR processing of the payment coupon imageas described above. In some instances, payment coupon metadata for theexact type of payment coupon received at block 405 may not be stored,even though some payment coupon metadata is stored for the identifiedbiller. In these cases, the payment service provider system 105 maysubsequently request payment coupon information at block 420.

Following block 425, or block 420 if the payer provided additionalpayment coupon information, is decision block 430. At decision block430, according to one embodiment, the payment service provider system105 determines whether the biller associated with the payment coupon isalready associated with the payer 110 as an approved biller. Forexample, a biller list (also referred to interchangeably as a “payeelist”) may be maintained for each payer 110 as a list of billers towhich the payer may frequently provide payment or otherwise transact,thus simplifying the transaction experience by the payer, allowingbillers to be easily displayed and selected, by already storing theproper biller information and the payer's account number with thebiller. Accordingly, at decision block 430, the biller's name or variantthereof, and/or any other biller identifying information, may becompared to the payer's biller list. It is appreciated that additionalinformation may be used to facilitate determining a match, such asaddress information, account information, or other stored authoritativeinformation (e.g., if a managed payee, etc.).

If it is determined that the biller is already associated with thepayer's biller list, then operations proceed to block 450 for displayingpayment information to the payer in a manner similar to that describedbelow with reference to block 435, after which decision block 455 isperformed. At decision block 455, a determination can be made as towhether any additional processing is to be performed, such as to processa payment request and/or to add the biller as an electronic biller.

However, if it is determined at decision block 430 that the biller isnot already associated with the payer's biller list, then the paymentservice provider system 105 may present to the payer 110 the billerinformation at block 435. For example, a webpage or other user interfacemay be presented that includes, but is not limited to, one or more ofthe following: the coupon image, the biller name, a payment amount, apayment date, and the like. Moreover, in some embodiments, one or moreof the payment coupon fields presented can be modifiable by the payer110, such as, but not limited to, the payment amount or the paymentdate. The biller name does not need to be modifiable because it wasalready matched to existing payment coupon metadata stored in thepayment coupon database; although, in some embodiments, it may beassociated with an option to allow changing the biller in the eventthere is an incorrect match (e.g., a hyperlink, one or more entryfields, etc.). The payment date initially displayed may be a paymentprocessing date different than, but based on, the payment coupon's duedate or it may be the due date itself. In some embodiments, the paymentdate may take into account a payment processing calendar or timeline tofacilitate determining and, optionally presenting, an earliest possibleprocessing or delivery date or any other strategically determinedpayment date. It is appreciated that, according to various embodiments,biller and/or payment information may be modified by the payer 110 atthis stage, or may be modified during subsequent operations, such as aredescribed with reference to block 455 and FIG. 6C, for example.

In addition to payment coupon information, an option to add the billerto the payer's biller list may be presented to the payer 110. Forexample, the option may be presented as a separate webpage (or otherinterface, such as within another webpage) providing the billerinformation and an ability to add the biller to the biller list. Inother embodiments, the option may be presented in conjunction with otherprocessing, such as when processing a payment request to the biller. Atdecision block 440 it is determined whether the biller is to be added tothe payer's biller list. If so, then block 445 follows in which thebiller is added. If not, then operations continue to decision block 455to determine whether additional processing is to be performed. In oneembodiment, it may be presumed that if payment request is beingprocessed the biller is to be added to the biller list, and mayoptionally be required to be added before processing a payment request.In these embodiments, the operations at blocks 440 and 445 may naturallyflow from, or otherwise be processed during, processing a paymentrequest. In other embodiments, however, a payer 110 may be presentedwith the option to explicitly request the biller be added to the payer'sbiller list.

At decision block 455, it may be determined whether a payment is to beprocessed in addition to adding the biller to the payer's biller list(if not already associated therewith). According to one embodiment, if apayment is not to be processed, operations end after decision block 455,as shown in FIG. 4A. However, in other embodiments, additionalprocessing may be performed, such as to determine whether the biller canbe activated as an electronic biller for the payer 110, as described atblock 465. In some embodiments, a payment may not be processed inresponse to receiving a payment coupon image from a payer 110, such asif the payer 110 is utilizing the payment coupon scanning functionalityonly to add the biller to the payer's list of billers. However, in otherembodiments, processing a payment may naturally follow the transmissionof a payment coupon image. In some embodiments, it may be presumed thata payment will be processed upon receiving and processing a paymentcoupon image, such that the next presentation to the user may includeboth the payment coupon information and an option to request paymentprocessing.

An example of a presentation containing both payment coupon informationand an option to request payment is illustrated by the user interface615 of FIG. 6C. As one example, FIG. 6C illustrates an example userinterface 615 in which payment coupon information and payment detailsare presented to the payer 110 along with an option to proceed withpaying the bill. In one embodiment, one or more of the fields presentingpayment coupon information and/or payment details may be modifiable bythe user, such as may be provided for the payment to be processed. Forexample, a payment amount and/or payment may be entered or updated bythe payer 110; though, it may be entered at another stage in theprocessing in other embodiments. It is appreciated that any number ofuser interface options for presenting biller information and paymentdetail to a payer 110 may be provided, and that the aforementionedexample is provided for illustrative purposes and is not intended to belimiting.

Accordingly, if it is determined at decision block 455 that a payment isto be processed, then operations continue to block 460 of FIG. 4B inwhich the payment is processed. According to one embodiment, whenissuing a command to process a payment, the payer 110 may have theability to modify one or more payment field values. For example, theuser interface 615 illustrated by FIG. 6C permits the payer 110 tomodify any of the field values, including, but not limited to, billername, biller address information, payer's account information, amountdue, date due, and payment date. However, in other embodiments, onlylimited field values may be altered by the payer 110, such as a paymentamount (not shown in FIG. 6C) and/or a payment date. Furthermore, inresponse to receiving the command to process a payment, the paymentservice provider system 105 may additionally transmit a confirmationrequest to the payer 110 prior to processing the payment with thebiller. A confirmation request may present the final field values to thepayer 110, to which the payer 110 may respond by confirming, optionallymodifying the values again, or cancelling the payment request. Theexample user interface 620 illustrated by FIG. 6D represents aconfirmation window that may be presented to the payer 110 that includespertinent payment information. After receiving confirmation by the payer110 (or automatically, in some embodiments), the payment serviceprovider system 105 may proceed to process a payment to the biller inresponse to the payment request via any one or more of a number ofmechanisms available, such as by delivering a paper instrument to thebiller, delivering paper remittance advice to the biller, delivering anelectronic image of a paper instrument to the biller system 130,delivering electronic remittance advice to the biller system 130,directing an electronic credit to a biller's account at the billerfinancial institution system 135, or directing an electronic debit tothe payer's account at the payer financial institution system 140.

After processing a payment, operations may continue at block 465. Atblock 465, the payment service provider system 105 may determine whetherthe biller supports electronic billing and, if so, activates the billeras an electronic biller of the payer 110 if requested to do so. Anelectronic biller allows paperless bill delivery to the payer 110electronically (e.g., via email, via a website, etc.) instead of, or inaddition to, receiving a paper bill with a payment coupon attached.Accordingly, the operations of the method 400 may be utilized by a payer110 to convert a biller from issuing paper bills to deliveringelectronic bills. It is possible that not all billers have the abilityor are otherwise unable to provide electronic billing, and thus cannotbe activated as an electronic biller. In one embodiment, the paymentservice provider system 105 maintains stored information identifying thecapabilities of billers and/or providing a list of known billers capableof electronic billing. If capable, at block 465, the payment serviceprovider system 105 may present the option to the payer 110 (e.g., via aseparate webpage or other interface presented from the webpage alreadybeing presented) to activate the biller as an electronic biller.

FIG. 6E illustrates an example user interface 625 that presents anoption to the payer 110 to activate the biller as an electronic billerfor the payer 110. In this example, the user interface 625 presents theoption to activate the biller as an electronic biller with aconfirmation that the payment has been scheduled. It is appreciated thatany number of user interface options for presenting an option to converta biller to an electronic biller may be provided, and that theaforementioned example is provided for illustrative purposes and is notintended to be limiting.

The method 400 may end after block 465 or 455, having received a scannedpayment coupon image from a payer 110 and performed OCR processing ofthe image to identify the biller, to optionally gather additionalpayment coupon information to update payment coupon metadata, tooptionally add the biller to the payer's biller list, to process apayment corresponding to the payment coupon, and/or to activate thebiller as an electronic biller for the payer 110.

It is appreciated that the described operations of the method 400 areprovided for illustrative purposes, and that additional operations maybe performed, less than all operations described may be performed,and/or alternative operations may be performed. For example, in anotherembodiment, instead of requesting the payer 110 to indicate paymentcoupon layout information at block 420, another entity may perform theseoperations, such as an individual associated with the payment serviceprovider, the biller, or a third-party entity. In one example of thisembodiment, rather than wait for the other entity to manually identifythe payment coupon layout, the payment service provider system 105 mayinstead instruct the payer 110 that the layout is unknown and requestthat payment be processed in another manner.

FIG. 5 represents a flow diagram of an example method 500 for capturinglayout information for a payment coupon image transmitted by a payer,according to one embodiment. For example, the operations of the method500 may be performed when payment coupon image metadata does not alreadyexist for the payment coupon's biller and/or payment coupon type, suchas would occur at block 420 of FIG. 4A described above. In response, thepayer 110 may utilize a unique user interface for identifying location,dimension, content, and value, of one or more payment coupon fields. Thepayment coupon layout information collected from the payer 110 can beadded to, or be used to update, the payment coupon metadata for thebiller, permitting more efficient processing of subsequent paymentcoupon images from the biller and/or of the same type.

Accordingly, in example embodiments, the operations of the method 500may be performed by one or more payment service provider computersassociated with a payment service provider system, such as the paymentservice provider computers 160 associated with the payment serviceprovider system 105 described with reference to FIG. 1. Exampleprocessing may be performed by one or more software application modulesof the payment service provider system, such as the coupon image module180 described with reference to FIG. 1. These operations may beperformed while interacting with a payer's device, such as a computer115 described with reference to FIG. 1. However, in other embodiments,certain operations of the method 500 may be performed by one or moreother components, such as by one or more suitable financial institutionsystems and/or by a payer's device, such as by a mobile device 125performing local processing, instead of, or in addition to, theoperations performed by the payment service provider system.

The method 500 may begin at block 505, in which a payment coupon imagethat was previously scanned and transmitted to the payment serviceprovider system 105 may be re-presented to the payer 110. Re-presentmentof a payment coupon image to a payer 110 would occur after it isdetermined that the payment coupon metadata does not contain metadataspecific to the received payment coupon type (e.g., no payment couponmetadata associated with the identified biller), such as is describedwith reference to blocks 415 and 420 of FIG. 4A. Accordingly, whenre-presenting the payment coupon image to the payer 110, instructionsare provided to the payer 110 to identify the layout of the paymentcoupon information and information regarding one or more payment couponfields. Payment coupon layout information may be provided by fieldindicators, which generally refer to information that indicates thelayout of the payment coupon, field locations, field type, and/orcontent. According to various embodiments, field indicators may include,but are not limited to, approximate locations, sizes, and/or dimensionsof various fields; field types; or field values. The example userinterface 630 illustrated by FIG. 6F represents a payment coupon imagepresented to a payer 110 with a request to provide field indicators,including the location of the biller address, the account number, theamount due, the date due, and the balance. It is appreciated that anynumber of user interface options for re-presenting a payment couponimage to a payer 110 and requesting field indicators may be provided,and that these examples and illustrations are provided for illustrativepurposes and are not intended to be limiting.

At block 510, the payment service provider system 105 may presentinstructions requesting a first field indicator from the payer 110. Theinstructions may request a field indicator for any of a number of fieldsfor which payment coupon metadata is to be captured and stored by thepayment service provider system 105, including, but not limited to,biller name (or other identifier), such as if the biller name isincorrect or not previously identified; biller address (e.g., street,city, state, zip, etc.); payer account number with the biller; paymentamount; amount due; payment date; or due date. A number of techniquesmay be provided for the payer 110 to indicate the field identifiergraphically on the image of the payment coupon being re-presented.

For example, in one embodiment, the payer 110 may drag, using a mouse orother input device, a box (or other geometry) or border indicating aspecific field type over the approximate location of the respectivefield on the image and size the box (e.g., by dragging a corner to alterthe dimensions) to approximately encompass the field. For example, withreference to the user interface 630 of FIG. 6F, each box, the billeraddress box, the account number box, the amount due box, the date duebox, and the balance box, identifies a field over which the box is to beplaced. By positioning, and optionally re-sizing, a box over arespective field, the application can determine a representativelocation, and optionally dimensions, of the field within the image bydetermining the location of the positioned box within the image. In someembodiments, the box may be approximately the same size and shape of thefield, such that the payer 110 need not re-size the box.

In another embodiment, the payer 110 may be instructed to click, using amouse or other input device, on or near a first corner of the respectivefield on the image and subsequently click on or near a second cornerthat is diametrically opposite the first corner, indicating theapproximate location of a diagonal formed across the field. Anothervariation of this technique may include the payer using a mouse or otherinput device to trace the approximate shape of a respective field or todrag the mouse pointer to form a rectangular shape that is approximatelythe same size and location of the field.

In yet other embodiments, the payer 110 may be instructed to click onother portions within or near a respective field on the image, such as,but not limited to, the approximate center of the field, four corners ofthe field, two opposing sides of the field (e.g., representing the widthor the height), all sides of the field (e.g., representing the width andheight), and the like. In one embodiment, in response to the payer's 110input, the presentation may display visual cues or other indications ofthe location(s) or area(s) identified by the payer, which may permitmodification or adjustment by the payer 110 prior to submission.

In response to the payer's 110 input identifying a field location and/ordimensions, the payment service provider system 105 can thus determinethe approximate location of the respective field within the instantpayment coupons and other payment coupons of that same type. Theunderlying data associated with a field indicator may be generated in anumber of ways, including, but not limited to, one or more x and ycoordinate pairs indicating an approximate location of the respectivefield within the image (e.g., an x and y coordinate pair representingcorners, side edges, top and bottom edges, and/or centers, etc.), one ormore horizontal or width dimensions, one or more vertical or heightdimensions, dimensions of a rectangle (or other geometry), one or moredistances from one or more predefined locations within the image (e.g.,a distance from the center or a distance from a specific corner, etc.),and the like. It is appreciated that the aforementioned examples of datarepresenting a field indicator are provided for illustrative purposes,and that any other suitable location and/or size measurement may beprovided.

Moreover, in some embodiments, the field indicator may further includean indication of the field type. For example, the field indicator mayidentify that the field is one of: a biller name field, a biller addressfield, an account number field, a payment amount field, an amount duefield, a due date field, a payment date field, and the like. Field typesmay be entered by the payer 110 (e.g., through a text input field or adropdown field, etc.), or they may already be associated with therespective field indicator input, such as if the instructions dictatewhich field is being identified or if a box or other shape beingpositioned and sized over a field is associated with a specific fieldtype.

In some embodiments, the field indicator may further include one or morefield values indicated in the instant payment coupon for the respectivefield. This may optionally be performed by the payer 110 at the time ofgenerating the field indicator, such as to avoid modifying a field valuelater or to add or alter a field value (e.g., to add a payment date orto alter a payment amount, etc.). However, in other embodiments, thepayment service provider system 105 may subsequently process each fieldlocation identified by the field indicators received using OCRprocessing to determine respective field values, as described withreference to block 530 below.

Accordingly, after entry of a field indicator by the payer 110, thefield indicator value or values may be transmitted to the paymentservice provider system 105 at block 515. Following block 515 isdecision block 520, in which it may be determined whether there areadditional fields for which field indicators are to be gathered from thepayer 110. For example, in one embodiment, field indicators areindividually transmitted from the payer 110 to the payment serviceprovider system 105 one at a time for processing individually uponreceipt, or for subsequent cumulative processing after receipt of allfield indicators. If additional field indicators are to be provided bythe payer 110, operations continue to block 525, in which the payer 110may be instructed to enter the next field indicator value in the same orsimilar manner as described with reference to blocks 510-515. However,in other embodiments, the payer 110 may provide field indicators formultiple fields of the payment coupon image at once, such that theoperations of blocks 510-525 are performed together.

After receipt of all field indicators, operations continue to block 530,in which the payment service provider system 105 may perform OCRprocessing on the payment coupon image to capture field values for eachfield based at least in part on the respective field indicatorinformation received for each field. After capturing field values, thepayment service provider system 105 may present one or more of the fieldvalues to the payer 110 for review, confirmation, and/or modification atblock 535. The image of the payment coupon may also optionally bepresented to the payer 110 at the same time (e.g., within the samewebpage, applet, or other interface) to permit simple review of both thevalue determined via OCR processing and the actual value of the paymentcoupon. In one embodiment, all field values are presented to the payer110 at once. The payer 110 may then review all fields at the same timeand alter, if necessary, any fields that are to be altered. However, inanother embodiment, the payment service provider system 105 may presenteach field value to the payer 110 individually, allowing the payer 110to individually review and either confirm or alter each field. In thisembodiment, processing would repeat until all fields have been presentedto the payer 110, and the values are confirmed and/or modified.

FIG. 6C illustrates an example user interface 615 in which all of thefield values are presented to the payer 110 for review and confirmationand/or modification. As mentioned, in one embodiment, a similar userinterface may be generated that also includes a presentation of thescanned payment coupon image.

In another embodiment, the payment coupon image may be displayed to thepayer 110 which includes the approximate location of each field based onthe field indicators provided by the payer 110. For example, the imagecould include a box or other shape (e.g., a border, etc.) represented onthe payment coupon image. If the location, shape, and/or dimensions ofone or more of the field locations presented to the payer 110 are notaccurately positioned, the payer 110 may re-position or otherwise alterthe field indicator to provide a more accurate indication of theapproximate location field within the payment coupon image.

It is appreciated that, while OCR processing is generally described asbeing performed by the payment service provider system 105, in otherembodiments, a fat client payment coupon imaging application may beconfigured to perform some or all payment coupon OCR scanning locally bythe payer's computer 115, instead of, or in addition to, being processedby the payment service provider system 105. For example, a paymentcoupon imaging application may include an OCR module operable to processa locally stored payment coupon image. In this embodiment, the paymentcoupon image may be stored locally for OCR processing, and the paymentcoupon field values extracted therefrom may be presented to the payer110 for review and confirmation and/or modification.

After display of one or more of the field values to the payer 110,decision block 540 follows. At decision block 540 it may be determinedwhether modifications are to be made to the payment coupon field valuesand/or payment coupon metadata (e.g., data represented by the fieldindicators) based on the payer's 110 response(s). If so, operationscontinue at block 545 in which the field values and/or payment couponmetadata may be updated or otherwise modified. After modification, or ifno modifications are to be performed at block 540, operations continueat block 550. At block 550, the payment service provider system 105 maystore or update payment coupon metadata and/or other payment couponinformation, such as may be stored in the payment coupon database 170.For example, the payment coupon layout information captured by the fieldindicators may be stored in the payment coupon database 170 andassociated with the biller identified for the payment coupon, allowingindexing and look-up by the biller. New or updated biller information,such as biller name (or other identifier), address, and/or biller phonenumber, may also be stored in the payment coupon database 170.

It is appreciated that, in some embodiments, payment coupon metadata mayinstead, or additionally, be associated with a payment coupon type,which may be specific to a single biller or may be a payment coupon typeutilized by multiple billers. Thus, in example embodiments, paymentcoupon metadata can be looked up by payment coupon type instead of, orin addition to, being looked up by biller name. In addition to paymentcoupon layout information, the payment service provider system 105 mayseparately store or otherwise maintain the field values associated withthe instant payment coupon, such as in temporary storage, a payments ortransactions database, and/or a biller database, to permit subsequentprocessing of the payment coupon. Subsequent transaction processing,such as, but not limited to, processing a payment request on behalf ofthe payer 110, adding a biller to the payer's 110 biller list, and/oractivating the biller as an electronic biller for the payer 110, isdescribed in more detail with reference to FIGS. 4A-4B.

The method 500 may end after block 550, having captured payment couponlayout information from the payer 110, which will permit processing theinstant and subsequent payment coupon images from the same biller(and/or of the same payment coupon type).

FIGS. 7A-7B represent a flow diagram of an example method 700 forcapturing a payment coupon image by a payer and transmitting the paymentcoupon image to a payment service provider for processing, according toone embodiment. However, in this embodiment, instead of utilizing acomputer 115 and a scanner device 120, the payer 110 uses a mobiledevice having a camera, such as a mobile device 125 described withreference to FIG. 1. The camera of the mobile device 125 can be used totake a digital photograph of a payment coupon. The mobile device 125 hasa display and interface that will allow presenting, identifying, and/ormodifying payment coupon layout and/or field values, if necessary.Accordingly, in example embodiments, certain operations of the method700 may be performed by one or more payment service provider computersassociated with a payment service provider system (e.g., thoseoperations on the left side of FIGS. 7A-7B), such as the payment serviceprovider computers 160 associated with the payment service providersystem 105 described with reference to FIG. 1, while other operationsmay be performed by a payer's mobile device 125 (e.g., those on theright side of FIGS. 7A-7B). It is appreciated, however, that in someembodiments, such as in embodiments utilizing a fat client applicationexecuted locally on a payer's mobile device 125, some or all of theoperations illustrated as being performed by the payment serviceprovider system 105 in FIGS. 7A-7B may be performed on the mobile devicewith the fat client application being executed locally. However, inother embodiments, certain operations of the method 700 may be performedby one or more other components, such as by one or more suitablefinancial institution systems instead of, or in addition to, theoperations performed by the payment service provider system.

According to one example embodiment, a payer's mobile device 125 isoperable for wireless transmissions directly with the payment serviceprovider system 105, such as over a wireless network 150 utilizing SMSand/or MMS messaging capabilities and a local or fat client mobilepayment coupon photo application installed and executed locally on themobile device 125. In another embodiment, the payer's mobile device 125is configured for Internet communications, and operable for accessing athin client mobile payment coupon photo application using a browserapplication over a network 145, such as the Internet, via a wirelessnetwork 150 adapted for Internet access. In yet another embodiment, thepayer's mobile device 125 may have a local or fat client mobile paymentcoupon photo application installed thereon, which provides forcommunications with the payment service provider system 105 over anetwork 145, such as the Internet, via a wireless network 150 adaptedfor Internet access. Accordingly, a fat client mobile payment couponphoto application may be downloaded over the network 145 from thepayment service provider system 105 (or other system) or installed fromlocal media (e.g., removable disc, removable storage drive, etc.). Inyet other embodiments, the mobile payment coupon photo application maybe provided as a combination of thin and fat client applications,primarily accessed over the network 145 and the wireless network 150 andexecuted utilizing a web browser, but having some functionality providedby locally executed applications, such as web applets operable forcontrolling or otherwise interacting with the mobile device's camera.Aside from the means by which the payment coupon image is captured(e.g., capturing a digital photograph) and possible means by which apayment coupon image may be transmitted to the payment service provider(e.g., as a MMS message in one embodiment), the method 700 is performedin a similar manner as the methods 300, 400 described with reference toFIGS. 3-4B. Accordingly, when describing the method 700 below, detailswill be provided for the operations that differ from the methods 300,400.

The method 700 may begin at block 705. At block 705, the payer 110 mayactivate a mobile payment coupon photo application on the mobile device125. If the application is a thin client application, the one or morewebpages may be transmitted over the network 145 (e.g., the Internet)via a wireless network 150 for display on the mobile device 125. If theapplication is a local fat client application, then the payer 110 mayinitiate the application on the mobile device 125. In one embodiment,the payer 110 may first download (or otherwise install) a local instanceof the application on the mobile device 125, such as if one has not yetbeen installed or if a new update is available after verifying thecurrent version with the payment service provider system 105.

Following block 705 is block 710 or, alternatively, block 712, in whichinstructions may be presented to the payer 110 to take a photograph ofthe payment coupon. If the mobile payment coupon photo application is athin client application, instructions may be transmitted from thepayment service provider system 105 at block 710. However, if theapplication is a fat client application, or at least certain portionsare executed locally, then the instructions may be provided in responseto local execution on the mobile device 125 at block 712.

Instructions presented to the payer 110 may generally includeinstructions such as, but not limited to, directing proper orientationof the payment coupon, selecting image resolution, and the like. FIG. 8Aillustrates an example user interface 805 of a mobile payment couponphoto application after instantiation and presenting instructions totake a photograph of a payment coupon using the mobile device 125. Inthe embodiment shown by the user interface 805, the mobile paymentcoupon photo application may integrate with, or otherwise issue acommand to, the camera of the mobile device 125. Accordingly, an inputoption (e.g., picture button, etc.) may be displayed that allows thepayer 110 to take a photograph within the application without requiringthe payer 110 to access the camera separately apart from theapplication. It is appreciated, however, that any number of userinterface options for a mobile payment coupon photo application may beprovided, and that the aforementioned examples and illustrations areprovided for illustrative purposes and are not intended to be limiting.

At block 715, the payer 110 uses the mobile device 125 to take aphotograph of the payment coupon as instructed. FIG. 8B illustrates anexample user interface 810 displaying a photograph of a payment couponusing the mobile device 125. After taking the photograph, the digitalimage of the payment coupon is transmitted to, and received by, thepayment service provider system 105 at blocks 720-725. According to oneembodiment, the payment coupon photograph may be transmitted to thepayment service provider system 105 over a network 145, such as theInternet, via a wireless network 150, such as if the mobile device 125is web-enabled. According to another embodiment, the payment couponphotograph may be transmitted to the payment service provider system 105as a message, such as a MMS message or any other suitable messagingprotocol, over the wireless network 150. In yet another embodiment, thepayment coupon photograph may be attached to an email to the paymentservice provider system 105, which may be generated from a templateprovided by the mobile payment coupon photo application.

At block 725, the payment service provider system 105 receives thepayment coupon photograph. Upon receipt, the payment service providersystem 105 may then attempt to identify the biller from the paymentcoupon photograph, in the same or similar manner as is described withreference to block 410 of FIG. 4A. If the biller name (or otheridentifier) is identified, it is determined whether payment couponmetadata exists for the biller at decision block 730, in the same orsimilar manner as is described with reference to block 415 of FIG. 4A.If the payment coupon metadata does exist for the biller and/or type ofpayment coupon, then operations continue to block 755 to determine fieldvalues for the payment coupon.

However, if it is determined at decision block 730 that payment couponmetadata has not already been captured for the biller and/or paymentcoupon type, then operations proceed to blocks 735-750 to capture fromthe payer 110 the layout of the payment coupon. At block 735, thepayment service provider system 105 may transmit a request andinstructions to the payer 110 to provide one or more field indicators ina manner similar to that described with reference to FIG. 5. The requestand instructions may be delivered as a new webpage, or may betransmitted as one or more commands to a local application to cause thelocal application to present the instructions and interface forcapturing the one or more field indicators. According to one embodiment,the payment coupon photograph, or a portion thereof, is also transmittedfor display to the payer 110, for use when providing the fieldindicators. In another embodiment, the application may recall a locallystored photograph instead of requiring a photograph be re-transmitted.

Thus, at block 740, the payer 110 may provide input to the mobile deviceto identify one or more field indicators, in a similar manner as isdescribed with reference to FIG. 5. Because the screen size of manymobile devices 125 may be limited, in one embodiment, only a portion ofthe payment coupon photograph is displayed at a time. The mobile device125 may enable the payer 110 to move the portion of the payment couponphotograph displayed (e.g., by touch screen, scroll wheel, pointer, orother input device). For example, the payment coupon photograph may besized such that a single field can be displayed at a time for entry ofone or more field indicators associated therewith.

A number of interface controls can be provided by the mobile paymentcoupon photo application, which may be similar to those described withreference to FIG. 5, for instance. In one example, the payer 110 may usea mobile device 125 input function (e.g., touch screen, scroll wheel,pointer, etc.) to identify the center of a field, one or more edges of afield (e.g., left, right, top, and/or bottom), or one or more corners(e.g., to indicate a diagonal across the field). Similarly, the payer110 may draw or otherwise position a rectangle or other shape outlininga field, and optionally re-size a drawn shape if desired. Drawing orpositioning a shape to outline a field may be better suited for a mobiledevice 125 having a touch screen interface; however, other input devicesmay be utilized in a similar manner as desired.

In one embodiment, one or more text entry fields may also be displayedto allow the payer 110 to enter alphanumeric field indicatorinformation. For example, a field type or a field value may be enteredwith the mobile device 125, as shown in blocks 740 and 745.

After providing one or more field indicators, and any additionalassociated payment coupon information, block 750 follows, in which thefield indicator or indicators may be transmitted to the payment serviceprovider system 105 for additional processing. In one embodiment, allfield indicators may be entered by the payer 110 all at once prior totransmitting to the payment service provider system 105. For example,the mobile payment coupon photo application may present a user interfacethat permits entry of more than one field indicator and requestssubmission and transmission when complete. In another embodiment,however, each field indicator may be transmitted to the payment serviceprovider system 105 separately. For example, a user interface mayinstruct the payer 110 to enter one field indicator at a time, andproceed in stepwise fashion to transmit the field indicator data to thepayment service provider system 105 after each entry.

Upon receiving field indicator data for one or more fields of thepayment coupon, the payment service provider system 105 may continue toprocess the payment coupon photograph at block 755 of FIG. 7B. Forexample, as described with reference to block 530 of FIG. 5, the paymentservice provider system 105 then performs OCR processing to determinefield values for one or more fields of the payment coupon based at leastin part on the field indicator data provided by the payer 110. It isappreciated that, according to one embodiment, one or more additionalpresentations may optionally be generated and transmitted to the payer'smobile device 125 that include information representing the fieldindicators and/or the payment coupon metadata, allowing the payer 110 toreview and confirm or modify the payment coupon metadata prior toperforming OCR processing to determine payment coupon field values. Thisadditional processing may be formed in the same or similar manner as isdescribed with reference to FIG. 5, such as at blocks 535-545, forexample.

After determining the field values, the payment service provider system105 may then transmit field values for the payment coupon to the payer'smobile device 125, over the Internet as a webpage or using messaging(e.g., SMS messaging, MMS messaging, etc.), at block 760. In oneembodiment, one or more of the field values are displayed in amodifiable user interface (e.g., text entry fields, etc.) to permitmodification by the payer 110 upon review if desired. In response, thepayer 110 may review, confirm, and/or modify one or more of the fieldvalues presented at block 765 and transmit the confirmation and/ormodification response back to the payment service provider system 105.FIG. 8C illustrates an example user interface 815 displaying each of thefield values in text entry fields on the mobile device 125. The userinterface 815 of this embodiment, therefore, allows the payer 110 tomodify one or more of the field values and/or request the payment beprocessed using the “pay” input option. It is appreciated, however, thatany number of user interface options for a mobile payment coupon photoapplication may be provided, and that the aforementioned examples andillustrations are provided for illustrative purposes and are notintended to be limiting.

It is appreciated that, while OCR processing is generally described asbeing performed by the payment service provider system 105, in otherembodiments, a fat client mobile payment coupon photo application may beconfigured to perform some or all payment coupon OCR scanning locally bythe mobile device 125, instead of, or in addition to, being processed bythe payment service provider system 105. For example, a mobile paymentcoupon photo application may include an OCR module operable to process alocally stored payment coupon photo. In this embodiment, the paymentcoupon photo may be stored locally for OCR processing, and the paymentcoupon field values extracted therefrom may be presented to the payer110 for review and confirmation and/or modification.

Upon receipt of the confirmation and/or modification response, thepayment service provider system 105 may continue processing the paymentcoupon photograph at block 770. For example, the payment serviceprovider system 105 may store and/or update payment coupon metadata orother information maintained in the payment coupon database 170 withfield indicator data and/or field value information received tofacilitate further processing of the instant payment coupon photographas well as any subsequent payment coupon photographs or images from thesame biller and/or of the same type, such as is described with referenceto block 550 of FIG. 5. In addition, the payment service provider system105 may also continue processing the payment coupon, such as, but notlimited to, processing a payment request on behalf of the payer 110,adding a biller to the payer's 110 biller list, and/or activating thebiller as an electronic biller for the payer 110. Subsequent transactionprocessing is described in more detail with reference to FIGS. 4A-4B.FIG. 8D, for example, illustrates an example user interface 820displaying a confirmation of a processed payment with an option for thepayer 110 to repeat the method 700 to capture another payment coupon.

The method 700 may end after block 770, having received a payment couponphotograph from a payer 110 utilizing a mobile device 125. In addition,in some instances of performing the method 700, payment coupon layout isdetermined, which will facilitate processing the payment couponphotographs and images from the biller and/or of the same type.

FIG. 9 represents a flow diagram of an example method 900 for capturingmultiple payment coupon images by a payer all at once and collectivelytransmitting all of the payment coupon images in a batch to a paymentservice provider for processing, according to one embodiment. Thismethod 900 is similar to the method 300 described with reference to FIG.3, although the payment coupon imaging application is configured toallow the payer to scan multiple payment coupons all at once, which maybe useful to efficiently add multiple billers to a payer's biller listor to efficiently process multiple payment requests. In exampleembodiments, certain operations of the method 900 may be performed byone or more payment service provider computers associated with a paymentservice provider system, such as the payment service provider computers160 associated with the payment service provider system 105 describedwith reference to FIG. 1, while other operations may be performed by apayer's computer and scanner device in communication therewith, such asa computer 115 and a scanner device 120 described with reference toFIG. 1. However, in other embodiments, certain operations of the method900 may be performed by one or more other components, such as by one ormore suitable financial institution systems instead of, or in additionto, the operations performed by the payment service provider system.Aside from the ability to scan and transmit multiple payment coupons allat once, the method 900 is performed in a similar manner as the method300 described with reference to FIG. 3. Accordingly, when describing themethod 900 below, details will be provided for the operations thatdiffer from the method 300.

The method 900 may begin at block 905. At block 905, an option to scanmultiple payment coupons may be presented to the payer 110 in the sameor similar manner as described with reference to block 305 of FIG. 3.Blocks 910-925 are performed in the same or similar manner as blocks310-325 of FIG. 3, receiving a payer's selection to provide multiplepayment coupon images, activating control (or otherwise interfacingwith) a scanner device 120, and presenting scanning instructions to thepayer 110, respectively. The instructions presented to the payer 110 atblock 925 may, in some instances, differ, including instructions forscanning multiple payment coupons all at once. For example, according toone embodiment, the payment coupon scanning instructions may requestthat the payer 110 scan the entire page on which each payment coupon isdisplayed. Because it is possible that different payment coupons couldhave different dimensions and occupy different real estate of therespective pages on which they are displayed, scanning multiple couponsmay be simplified by scanning entire pages. It is appreciated, however,that the payment coupon imaging application may be configured to allowseparating each payment coupon from the page on which it displayed andto instruct the payer 110 accordingly. Moreover, in various embodiments,instructions are presented as to how to feed or otherwise orient eachpayment coupon with the scanner device 120. For example, scanningmultiple payment coupons may be simplified even more for the payer 110if the scanner device 120 includes an automatic feed capability.However, depending upon the scanner device 120, the payment couponimaging application may allow for, and the instructions presented mayinstruct, manual feeding of each respective payment coupon, even fortransmissions including a batch of payment coupon images.

Following block 925 are blocks 930-940, in which the payer 110 mayactivate the scanner device 120 at block 930, and scan multiple paymentcoupons at block 935, repeating blocks 935-940 for each payment couponscanned. For example, a first payment coupon may be scanned at block 935and stored, at least temporarily, in the local memory of the computer115. After block 935, decision block 940 determines whether additionalpayment coupons are to be scanned. This determination may be made in anumber of ways. For example, in an embodiment in which the paymentcoupons are being automatically fed into the scanner device 120, thescanner device 120 will continue to scan until there are no additionalpages to scan, as is done with conventional multiple page scans. In oneembodiment, scanning each payment coupon is coordinated, or otherwisefacilitated, at least in part by the payment coupon imaging application,such as with an applet or other integration means between theapplication and the scanner device 120, as described with reference toFIG. 3. In an embodiment in which the payment coupons are being manuallyfed or otherwise placed with the scanner device 120, then the paymentcoupon imaging application may present instructions and coordinatescanning for each individual payment coupon. For example, after a firstscan is performed, the payment coupon imaging application may solicitthe payer's 110 input as to whether additional payment coupons are to bescanned and/or input or when to perform scanning on the next paymentcoupon after it is positioned with the scanner device 120. In eitherembodiment, automatic or manual feeding, the payment coupon imagingapplication may include an input option which the payer 110 selects whenall payment coupons have been scanned and scanning is completed (e.g.,“finished,” “complete,” “done,” etc.). Accordingly, blocks 935 and 940are repeated until there are no more payment coupons to be scannedand/or until the payer 110 indicates that scanning is completed.

After all payment coupons are scanned at the payer's computer 115,operations continue to block 945. At block 945, the payer 110 may theninstruct transmission of the batch of scanned payment coupon images tothe payment service provider system 105. Each payment coupon image maybe retrieved from a local memory of the payer's computer 115 prior totransmission. In one embodiment, similar to that described withreference to block 340 of FIG. 3 and the user interface 610 of FIG. 6B,the scanned payment coupon images may be displayed to the payer 110prior to transmission to the payment service provider system 105. Uponreceiving the batch of scanned payment coupon images at block 950, thepayment service provider system 105 may then proceed to process thebatch of payment coupon images, such as is described in more detail withreference to FIGS. 10A-10B.

After receiving the batch of payment coupon images, the method 900 mayend, having enabled a payer 110 to utilize a computer 115 and a scannerdevice 120 to capture payment coupon information from multiple bills andtransmit the batch of payment coupon images to a payment serviceprovider system 105.

FIGS. 10A-10B represent a flow diagram of an example method 1000 forprocessing a batch of payment coupon images transmitted by a payer,according to one embodiment. This method 1000 is similar to the method400 described with reference to FIGS. 4A-4B, with the exception that thepayment service provider system 105 is configured to process multiplecoupon images all at once, simplifying payer transactions containing arequest for processing of multiple items. Example processing may beperformed by one or more software application modules of the paymentservice provider system, such as the coupon image module 180 describedwith reference to FIG. 1. Example operations include, but are notlimited to, capturing payment coupon metadata or other information,adding one or more billers to a payer's biller list, activating one ormore billers as electronic billers, and/or processing one or morepayment requests corresponding to payment coupons received in the batchof payment coupon images. In example embodiments, certain operations ofthe method 1000 may be performed by one or more payment service providercomputers associated with a payment service provider system, such as thepayment service provider computers 160 associated with the paymentservice provider system 105 described with reference to FIG. 1. However,in other embodiments, certain operations of the method 1000 may beperformed by one or more other components, such as by one or moresuitable financial institution systems and/or by a payer's device, suchas by a mobile device 125 performing local processing, instead of, or inaddition to, the operations performed by the payment service providersystem.

The method 1000 may begin at block 1005. At block 1005, the paymentservice provider system 105 receives a batch of multiple scanned paymentcoupon images from a payer's computer 115, as described with referenceto FIG. 9. Each payment coupon image may represent only the respectivepayment coupon, such as if the payer 110 separated the payment couponfrom the page on which it is displayed, or each may represent an entirescanned bill page containing a respective payment coupon and otherimmaterial information. Additional processing may optionally beperformed to first identify and isolate each payment coupon from theimmaterial portion of the respective image if it is determined that theimages received at block 1005 represent more than the payment coupon(e.g., if the payment coupon was not separated from the rest of thepage). Details of example operations to identify and isolate the paymentcoupon area from an entire image are described in more detail withreference to blocks 330-340 of FIG. 3.

Following block 1005 is block 1010, in which a pointer, counter, orother means to designate which of the multiple payment coupon images isbeing processed, may be set to the first payment coupon image. A pointeror other similar means facilitates looping through the processing inblocks 1015-1050 for each payment coupon image in the batch. Next, atblock 1015, the payment service provider system 105 may locate a billername or other biller identifier from the first payment coupon image ofthe batch (or subsequent image being processed), such as via OCRprocessing, in the same or similar manner as described with reference toblock 410 of FIG. 4A.

In one embodiment, if no biller information is discernable from thepayment coupon image at block 1015, the payment service provider system105 may initially reject the payment coupon image, requiring the payer110 to process the corresponding payment coupon via other techniques.The payment service provider system 105 may store a rejection indicatorto permit indicating rejected payment coupon images all at once afterprocessing all payment coupon images in the batch to avoid disruptingthe processing flow of the multiple coupon image processing. Though, inother embodiments, the payer 110 may be notified for each rejectedpayment coupon image as it is being processed.

Following block 1015 is decision block 1020, in which the paymentservice provider system 105 may compare the biller information obtainedfrom the payment coupon image at block 1015 to stored payment couponmetadata, such as may be stored in the payment coupon database 170described with reference to FIG. 1. Payment coupon metadata associatedwith the biller indicates whether the layout of the payment couponreceived from the biller is known. The operations of block 1020 can beperformed in the same or similar manner as is described with referenceto block 415 of FIG. 4A.

If it is determined at decision block 1020 that payment coupon metadatadoes exist for the biller identified, then operations continue to block1025 to determine payment coupon information from the payment couponimage being processed utilizing OCR processing and the known paymentcoupon layout provided by the payment coupon metadata for paymentcoupons from this biller. Payment coupon information may be determinedin the same or similar manner as is described with reference to block425 of FIG. 4A, such as to locate one or more payment coupon fields anddetermine the field values for the respective fields.

At decision block 1030, the payment service provider system 105 maydetermine whether the biller associated with the payment coupon isalready associated with the payer 110 as an approved biller in thepayer's biller list in the same or similar manner as is described withreference to block 430 of FIG. 4A. If the biller is not alreadyassociated with the payer's biller list, then, at block 1035, an “addbiller flag” or other indicator may be set for the payment coupon imagebeing processed to permit subsequent indication that the biller is notin the payer's biller list and/or to request adding the biller to thepayer's biller list. It is appreciated that in other embodiments,instead of, or in addition to, setting a flag for subsequent action, thepayment service provider system 105 may transmit a notification andrequest to the payer's computer 115 while processing the payment couponimage; although, this may slightly disrupt the more efficient batchprocessing at least from the payer's perspective.

However, if it is determined at decision block 1020 that payment couponmetadata does not exist for the biller identified, then operationscontinue to block 1040, in which a reject status or other indicator maybe set for the payment coupon image being processed to indicate that thepayment coupon layout is unknown. In one embodiment, rejected paymentcoupon images may simply be indicated as such to the payer 110, andrequire processing of the payment coupon by another technique. However,in other embodiments, one or more of the rejected payment coupon imagesmay be presented to the payer 110 (e.g., re-transmitting the image tothe payer's computer 115) for the payer 110 to indicate the paymentcoupon layout, such as by providing one or more field indicators and/orfield values for each field of the payment coupon, in the same orsimilar manner as is described in more detail with reference to FIG. 5.

Following one of blocks 1030, 1035, or 1040 is decision block 1045. Atdecision block 1045, it may be determined whether there are anyadditional payment coupon images in the batch to be processed. If thereare additional payment coupon images, then the pointer, counter, orother means to designate which of the multiple payment coupon images isbeing processed, is increased to indicate the next payment coupon imageat block 1050, and the operations of blocks 1015-1045 are repeated untilall payment coupon images of the batch have been processed.

After all payment coupon images of the batch have been processed,operations continue to block 1055. According to one embodiment, at block1055, a presentation of all payment coupons that were able to beprocessed (e.g., those not rejected above at block 1040) andcorresponding payment coupon information determined at block 1025 may bepresented to the payer 110. For example, in one embodiment, a userinterface may display the scanned image for each payment coupon inaddition to field values for each field of the respective paymentcoupon. The scanned image may be displayed in a large format occupying asignificant portion of the display or may be displayed in a smallerformat, such as a thumbnail or icon that can optionally be selected forexpansion by the payer 110. One or more of the field values may bemodifiable by the payer 110 (e.g., text entry field, etc.), allowing thepayer 110 to correct or modify field values determined by the paymentservice provider system 105 via OCR processing. The payer 110 may thenscroll or otherwise navigate the user interface to view each paymentcoupon processed. In another embodiment, the user interface may containa simplified list view, listing field values and other pertinentinformation for each payment coupon processed. For example, a row foreach payment coupon processed may be displayed with field values incolumns, one or more of which may be modifiable.

Information to be presented at block 1055 may include, but is notlimited to, biller name (or other identifier), biller address, accountinformation, amount due, payment amount, date due, payment date, and thelike. It is appreciated that, in some embodiments, fields that are notmodifiable (e.g., biller address information for which there was a matchin the payment coupon database 170, and thus presumed accurate) may notbe presented to the payer at all to simplify the user interface andconserve display real estate. In addition, the payment couponinformation presented may further include an indication as to whetherthe respective biller is already associated with the payer's biller listand/or whether the biller is already an electronic biller for the payer110 if the biller supports electronic billing. It is appreciated thatany number of user interfaces and means for displaying payment couponinformation may be provided, and that the aforementioned examples areillustrative and not intended to be limiting.

Accordingly, upon presenting the payment coupon information to the payer110, the payer 110 may review, confirm, and/or modify informationpresented for one or more of the payment coupons, in a similar manner asis described with reference to blocks 540-545 of FIG. 5. For example,the payer may confirm some information as provided and provide amodification of others by providing desired input into one or moreassociated text entry fields. In addition, in some embodiments, thepayer 110 may indicate whether a biller not already added to the billerlist is to be added and/or whether a capable biller not alreadydesignated as an electronic biller is to be activated as an electronicbiller.

Therefore, following block 1055 is block 1060 of FIG. 10B, in which thepayment service provider system 105 may receive confirmation ormodification for each of the presented payment coupons. Upon receivingthe confirmation and/or modifications, the payment service providersystem 105 may then process each payment coupon to add the respectivebiller to the payer's biller list at block 1065 if requested, toactivate the respective biller as an electronic biller at block 1070 ifcapable and if requested, and/or to process a payment corresponding tothe respective payment coupon at block 1075 if requested.

Any or all of blocks 1065-1075 may be performed for each of the paymentcoupon images processed. For example, a payer 110 may not wish to addevery biller identified to a biller list, or a payer 110 may not wish toreceive electronic bills from every biller identified. Similarly, insome instances, a payment request may not be processed for every (orany) payment coupon images processed, such as if the payer 110 utilizesthe batch payment coupon scanning operations for the purpose of addingbillers but not to process payment requests. It is further appreciatedthat these subsequent processing operations may be performed in anyorder, for example, any payment requests may be processed prior toadding billers to a biller list or activating electronic billers.

Moreover, it is further appreciated that, according to some embodiments,separate requests to add billers to a biller list and/or to activatebillers as electronic billers may be presented to the payer 110. Forexample, these requests can be performed after processing any paymentrequests to avoid disrupting more efficient batch payment requestprocessing, saving any additional transaction processing with the payer110 until payment request processing is complete. In one exampleembodiment, a user interface may contain a single display of all thebillers, and optionally any corresponding biller information (e.g.,address, etc.) and/or payer information (e.g., payer's account with thebiller, etc.), from payment coupons that are capable of electronicbilling but not yet activated for the user. A similar user interface canbe presented for billers not yet associated with the payer's billerlist. In response, the payer 110 can then provide any needed informationand submit a request to activate the billers as electronic billersand/or to add the billers to the payer's biller list, as desired, in asingle submission. In another embodiment, information for each billerfor which there is an opportunity to add to a biller list or to activateas an electronic biller can be displayed individually, allowing thepayer 110 to respond separately for each biller.

Although not illustrated, in some embodiments, additional operations mayinclude obtaining from the payer 110 payment coupon layout information(e.g., field indicators identifying approximate field locations, sizes,dimensions, types, etc.) for those payment coupon images of the batchfor which no payment coupon metadata existed in the payment coupondatabase 170, as determined at block 1020. The operations for obtainingpayment coupon layout information may be performed in the same orsimilar manner as described with reference to FIG. 5. In one embodiment,payment coupon layout information may be gathered from the payer 110after performing the above operations. In this manner, payment couponlayout information will be gathered after completing processing for thepayment coupon images for which processing can be performed. The payer110 may therefore elect to provide payment coupon layout information ormay decline to do so without causing a significant interruption in theother transaction processing. However, in other embodiments, the paymentcoupon layout information may be gathered at various other stages of themethod 1000, such as after block 1040 when it is initially determinedthat no payment coupon metadata exists, or at once immediately prior to,or after, displaying the payment coupon information for those capable ofbeing processed at block 1055.

The method 1000 may end after block 1075, or after any additionalprocessing as described above, having received a batch of scannedpayment coupon images from a payer 110 and performed OCR processing oneach image to identify the biller, and to perform subsequent processingrequested therefor.

Accordingly, the systems and methods described herein provide a uniqueapproach to processing payment and other related transactions utilizingpaper bills exactly as delivered by billers. Payers' efforts may besimplified by only requiring that the payer scan the payment coupon asreceived utilizing a computer and scanner device, or take a digitalphotograph of the coupon utilizing a mobile device camera, and transmitthe scanned image to a payment service provider system for processing.If payment coupon metadata exists for the payment coupon biller and/ortype sent, then the payment service provider can process the paymentcoupon without requiring an overabundance of input from the payer. Ifthe payment coupon metadata does not exist for the biller or type, thenthe payment service provider can shift the responsibility and effort toidentify the payment coupon layout to the payers, significantly reducingthe generation and maintenance of payment coupon metadata. For some,processing payment requests by scanning or taking a digital photographmay be the normal mode for payers, instead of the conventional manualtext-based techniques. For others, scanning or taking digitalphotographs of payment coupons may be used to facilitate the initialset-up for a first-time biller or to activate the biller as anelectronic biller, while relying on more conventional techniques forrepeated payment requests.

Accordingly, the example systems and methods described herein providethe ability for a payer who initially receives a paper bill to transformthe paper bill into an electronic version for enabling the paymentservice provider systems to perform new or additional processingassociated with information extracted from the electronic version. Apayment coupon is transformed to an electronic version at leastpartially by scanning or photographing a paper payment coupon togenerate a digital image representing the payment coupon. In addition,the payment service provider system further transforms the paymentcoupon digital image by performing OCR processing to identify andextract biller and/or payment coupon information from the digital image.The additional uses provided for by this transformation of a paymentcoupon into a digital image and the subsequent extraction of fieldvalues include adding the biller associated with the underlying paperpayment coupon to a payer's biller list, activating the biller as anelectronic biller for the payer, and/or processing a payment requestwith the biller on behalf of the payer based at least in part on dataextracted from the payment coupon digital image. Moreover, additionaluses provided for by the transformation of the paper payment coupon to adigital image include the generation of payment coupon metadata forbillers and/or payment coupon types that are unknown to the paymentservice provider system, enabling subsequent processing of the instantand later received digital images. Therefore, by undergoing atransformation from a paper payment coupon to a digital image and/ordata extracted therefrom, different functions and different uses by apayment service provider system are provided.

The operations described and shown with reference to the above methods300, 400, 500, 700, 900, and 1000 may be carried out or performed in anysuitable order as desired in various embodiments of the invention.Additionally, in certain embodiments, at least a portion of theoperations may be carried out in parallel. Furthermore, in certainembodiments, less than or more than the operations described herein maybe performed. Additionally, although the methods 300, 400, 500, 700,900, and 1000 describe operations by which payment coupon imageinformation is received from a payer, similar operations may be utilizedto process the receipt of similar coupon information from any otherentity.

The invention is described above with reference to block and flowdiagrams of systems, methods, apparatus, and/or computer programproducts according to example embodiments of the invention. It will beunderstood that one or more blocks of the block diagrams and flowdiagrams, and combinations of blocks in the block diagrams and flowdiagrams, respectively, can be implemented by computer-executableprogram instructions. Likewise, some blocks of the block diagrams andflow diagrams may not necessarily need to be performed in the orderpresented, or may not necessarily need to be performed at all, accordingto some embodiments of the invention.

These computer-executable program instructions may be loaded onto ageneral-purpose computer, a special-purpose computer, a processor, orother programmable data processing apparatus to produce a particularmachine, such that the instructions that execute on the computer,processor, or other programmable data processing apparatus create meansfor implementing one or more functions specified in the flow diagramblock or blocks. These computer program instructions may also be storedin a computer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meansthat implement one or more functions specified in the flow diagram blockor blocks. As an example, embodiments of the invention may provide for acomputer program product, comprising a computer usable medium having acomputer-readable program code or program instructions embodied therein,said computer-readable program code adapted to be executed to implementone or more functions specified in the flow diagram block or blocks. Thecomputer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational elements or steps to be performed on the computer or otherprogrammable apparatus to produce a computer-implemented process suchthat the instructions that execute on the computer or other programmableapparatus provide elements or steps for implementing the functionsspecified in the flow diagram block or blocks.

Accordingly, blocks of the block diagrams and flow diagrams supportcombinations of means for performing the specified functions,combinations of elements or steps for performing the specifiedfunctions, and program instruction means for performing the specifiedfunctions. It will also be understood that each block of the blockdiagrams and flow diagrams, and combinations of blocks in the blockdiagrams and flow diagrams, can be implemented by special-purpose,hardware-based computer systems that perform the specified functions,elements or steps, or combinations of special-purpose hardware andcomputer instructions.

Many modifications and other embodiments of the invention will come tomind to one skilled in the art to which this invention pertains andhaving the benefit of the teachings presented in the foregoingdescriptions and the associated drawings. Therefore, it is to beunderstood that the invention is not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1. A method, comprising: receiving, by a computerized payment serviceprovider system comprising one or more computers on behalf of a payer,an image representing a payment coupon; determining, by the computerizedpayment service provider system, an identity of a biller associated withthe payment coupon utilizing optical character recognition processing onat least one predetermined first location in the image; determining, bythe computerized payment service provider system based at least in partupon the identity of the biller, whether stored payment coupon metadataindicating a layout of the payment coupon is available; and extracting,by the computerized payment service provider system when the paymentcoupon metadata is available, data from the image based at least in parton the payment coupon metadata, wherein extracting data from the imagecomprises performing optical character recognition processing on one ormore predetermined second locations in the image based at least in parton the payment coupon metadata, or executing, by the computerizedpayment service provider system when payment coupon metadata is notavailable, a process to (i) receive payer input for facilitating dataextraction from the image and (ii) extract the data from the image basedat least in part upon received payer input, wherein extracting data fromthe image comprises performing optical character recognition processingon one or more predetermined second locations in the image based atleast in part on the received payer input.
 2. The method of claim 1,further comprising: performing, by the computerized payment serviceprovider system based at least in part upon the extracted data, at leastone of: (a) processing a payment associated with the payment coupon tothe biller; (b) adding the biller to a list of payees for the payer; or(c) activating the biller as an electronic biller for the payer.
 3. Themethod of claim 1, wherein the image comprises one of: (a) a scannedimage of the payment coupon; or (b) a photograph of the payment coupon.4. The method of claim 2, wherein performing at least one of: (a)processing the payment associated with the payment coupon to the biller;(b) adding the biller to the list of payees for the payer; or (c)activating the biller as an electronic biller for the payer comprises:determining that the biller is not associated with the list of payeesfor the payer; and adding the biller to the list of payees.
 5. Themethod of claim 4, wherein extracting data from the image furthercomprises: extracting an account identifier for the payer from theimage; and storing the account identifier in association with the payer.6. The method of claim 4, wherein extracting data from the image furthercomprises: extracting an address for the biller from the image; andstoring the address in association with the biller.
 7. The method ofclaim 2, wherein performing at least one of: (a) processing the paymentassociated with the payment coupon to the biller; (b) adding the billerto the list of payees for the payer; or (c) activating the biller as anelectronic biller for the payer comprises: determining that the billeris not activated as an electronic biller for the payer; and activatingthe biller as an electronic biller for the payer.
 8. The method of claim7, wherein extracting data from the image further comprises: extractingan address for the biller from the image; and storing the address inassociation with the biller.
 9. The method of claim 2, whereinperforming at least one of: (a) processing the payment associated withthe payment coupon to the biller; (b) adding the biller to the list ofpayees for the payer; or (c) activating the biller as an electronicbiller for the payer comprises: extracting payment information from theimage; and directing a payment to the biller on behalf of the payerbased at least in part on the payment information and the identity ofthe biller.
 10. The method of claim 9, wherein the payment informationcomprises at least one of: (a) a payment amount; (b) an accountidentifier for the payer; or (c) a payment date associated with thepayment coupon.
 11. The method of claim 9, further comprising, prior todirecting the payment, communicating the payment information to thepayer for confirmation or modification.
 12. The method of claim 1,wherein the payment coupon metadata is previously stored in associationwith the biller.
 13. The method of claim 1, wherein the payment couponmetadata is captured based at least in part upon the received payerinput.
 14. The method of claim 13, wherein it is determined that thatpayment coupon metadata is not available, and further comprising:requesting a respective set of one or more field indicators for each ofone or more fields with the image, wherein each respective set of one ormore field indicators represent at least one of i) an approximate sizeof the corresponding field, or ii) an approximate location of thecorresponding field; receiving, as the payer input, the respective setof one or more field indicators for the one or more fields within theimage; and storing information associated with the respective set of oneor more field indicators for the one or more fields within the image asthe payment coupon metadata in association with the biller.
 15. Asystem, comprising: at least one memory comprising computer-executableinstructions; at least one communications interface; and at least oneprocessor in communication with the at least one communicationsinterface, and the at least one memory and configured to execute thecomputer-executable instructions to: receive, via the at least onecommunication interface, an image representing a payment coupon;determine an identity of a biller associated with the payment couponutilizing optical character recognition processing on at least one firstpredetermined location in the image; determine, based at least in partupon the identity of the biller, whether stored payment coupon metadataindicating a layout of the payment coupon is available; and extract,when payment coupon metadata is available, data from the image based atleast in part on the payment coupon metadata, wherein the extractionincludes optical character recognition processing at one or more secondpredetermined locations in the image based at least in part on thepayment coupon metadata, or execute, when payment coupon metadata is notavailable, a process to (i) receive payer input for facilitating dataextraction from the image and (ii) extract the data from the image basedat least in part upon received payer input, wherein the extractionincludes optical character recognition processing at one or more secondpredetermined locations in the image based at least in part on thereceived payer input.
 16. The system of claim 15, wherein the at leastone processor is further configured to execute computer executableinstructions to perform, based at least in part upon the extracted data,at least one of: (a) processing a payment associated with the paymentcoupon to the biller; (b) adding the biller to a list of payees for thepayer; or (c) activating the biller as an electronic biller for thepayer. 16-26. (canceled)
 27. A system, comprising: at least one memorycomprising computer-executable instructions; at least one communicationsinterface; and at least one processor in communication with the at leastone communications interface, and the at least one memory and configuredto execute the computer-executable instructions to: receive, via the atleast one communications interface, an image representing a paymentcoupon; perform optical character recognition processing on at least onepredetermined biller location in the image to determine an identity of abiller associated with the payment coupon; if the optical characterrecognition processing determines the identity of the biller, then:determine, by the payment service provider system based at least in partupon the biller identity, whether stored payment coupon metadataindicating a layout of the payment coupon is available, and extract, bythe payment service provider system when payment coupon metadata isavailable, data from the image based at least in part on the paymentcoupon metadata, wherein the extraction includes optical characterrecognition processing at one or more second predetermined locations inthe image based at least in part on the payment coupon metadata, orexecute, by the payment service provider system when payment couponmetadata is not available, a process to (i) receive payer input forfacilitating data extraction from the image and (ii) extract the datafrom the image based at least in part upon received payer input, whereinthe extraction includes optical character recognition processing at oneor more second predetermined locations in the image based at least inpart on the received payer input, or if the optical characterrecognition processing fails to determine the identity of the biller,then: receive, by the payment service provider on behalf of the payer,the identity of biller, determine, by the payment service providersystem based at least in part upon the biller identity, whether storedpayment coupon metadata indicating a layout of the payment coupon isavailable, and extract, by the payment service provider system whenpayment coupon metadata is available, data from the image based at leastin part on the payment coupon metadata, wherein the extraction includesoptical character recognition processing at one or more secondpredetermined locations in the image based at least in part on thepayment coupon metadata, or execute, by the payment service providersystem when payment coupon metadata is not available, a process to (i)receive payer input for facilitating data extraction from the image and(ii) extract the data from the image based at least in part uponreceived payer input, wherein the extraction includes optical characterrecognition processing at one or more second predetermined locations inthe image based at least in part on the received payer input.
 28. Thesystem of claim 27, wherein the at least one processor is furtherconfigured to execute computer executable instructions to perform, bythe payment service provider system based at least in part upon theextracted data, at least one of: (a) processing a payment associatedwith the payment coupon to the biller; (b) adding the biller to a listof payees for the payer; or (c) activating the biller as an electronicbiller for the payer.
 29. The system of claim 28, wherein the computerexecutable instructions to perform at least one of: (a) processing thepayment associated with the payment coupon to the biller; (b) adding thebiller to the list of payees for the payer; or (c) activating the billeras an electronic biller for the payer comprise computer executableinstructions to: extract payment information from the image; and directa payment to the biller on behalf of the payer based at least in part onthe payment information and the identity of the biller.
 30. The systemof claim 27, wherein at least a portion of the stored payment couponmetadata was previously determined based at least in part upon inputreceived from one or more payers. 31-50. (canceled)